Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #29649 > unrolled thread

Xorg Libinput with Static Nodes

Back to article view | Back to comp.os.linux.misc

Contents

  Xorg Libinput with Static Nodes F Russell <fr@random.info> - 2020-04-05 22:17 +0000
    Re: Xorg Libinput with Static Nodes F Russell <fr@random.info> - 2020-04-05 22:47 +0000
    Re: Xorg Libinput with Static Nodes "J.O. Aho" <user@example.net> - 2020-04-06 07:02 +0200
      Re: Xorg Libinput with Static Nodes "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2020-04-06 01:32 -0400
        Re: Xorg Libinput with Static Nodes "J.O. Aho" <user@example.net> - 2020-04-06 10:44 +0200
          Re: Xorg Libinput with Static Nodes "Carlos E.R." <robin_listas@es.invalid> - 2020-04-06 11:08 +0200
            Re: Xorg Libinput with Static Nodes Paul <nospam@needed.invalid> - 2020-04-06 05:53 -0400
              Re: Xorg Libinput with Static Nodes "Carlos E.R." <robin_listas@es.invalid> - 2020-04-07 01:37 +0200
            Re: Xorg Libinput with Static Nodes "J.O. Aho" <user@example.net> - 2020-04-06 13:05 +0200
      Re: Xorg Libinput with Static Nodes "Carlos E.R." <robin_listas@es.invalid> - 2020-04-06 11:12 +0200
      Re: Xorg Libinput with Static Nodes F Russell <fr@random.info> - 2020-04-06 11:24 +0000
        Re: Xorg Libinput with Static Nodes Jasen Betts <jasen@xnet.co.nz> - 2020-04-06 12:00 +0000
        Re: Xorg Libinput with Static Nodes Paul <nospam@needed.invalid> - 2020-04-06 08:05 -0400
          Re: Xorg Libinput with Static Nodes F Russell <fr@random.info> - 2020-04-06 13:45 +0000
    Re: Xorg Libinput with Static Nodes "J.O. Aho" <user@example.net> - 2020-04-06 13:24 +0200
      Re: Xorg Libinput with Static Nodes F Russell <fr@random.info> - 2020-04-06 11:41 +0000
        Re: Xorg Libinput with Static Nodes "J.O. Aho" <user@example.net> - 2020-04-06 15:53 +0200
          Re: Xorg Libinput with Static Nodes F Russell <fr@random.info> - 2020-04-06 14:14 +0000
            Re: Xorg Libinput with Static Nodes Rich <rich@example.invalid> - 2020-04-06 14:19 +0000
              Re: Xorg Libinput with Static Nodes Fenris <fenris@invalid.invalid> - 2020-04-06 14:29 +0000
                Re: Xorg Libinput with Static Nodes DecadentLinuxUserNumeroUno@decadence.org - 2020-04-06 15:27 +0000
            Re: Xorg Libinput with Static Nodes "J.O. Aho" <user@example.net> - 2020-04-06 17:04 +0200
      Re: Xorg Libinput with Static Nodes F Russell <fr@random.info> - 2020-04-06 12:19 +0000
        Re: Xorg Libinput with Static Nodes "J.O. Aho" <user@example.net> - 2020-04-06 16:09 +0200
          Re: Xorg Libinput with Static Nodes F Russell <fr@random.info> - 2020-04-06 14:46 +0000
    Re: Xorg Libinput with Static Nodes "Carlos E.R." <robin_listas@es.invalid> - 2020-04-06 22:53 +0200
      Re: Xorg Libinput with Static Nodes DecadentLinuxUserNumeroUno@decadence.org - 2020-04-07 20:50 +0000

Page 1 of 2  [1] 2  Next page →

#29649 — Xorg Libinput with Static Nodes

The folks at xorg, in their move from simple input drivers
to complex abstraction layers, are getting ready to remove
the legacy keyboard and mouse drivers.

This will leave me in a lurch because I am still using
the simple keyboard and mouse drivers along with static
device nodes.  (If it ain't broke don't fix it.)

But I need to plan for the future.

Is there a way to use the new xorg libinput driver with
static device nodes?  My kernel is configured with evdev
and the keyboard and mouse should be accessible though
/dev/input/event* nodes.  But how do I determine which node?

Would it be possible to use xorg.conf to configure this,
as shown here:

Section "InputDevice"
Identifier "Keyboard1"
Driver "libinput"
Option "Device" "/dev/input/event???"
Option "XkbRules" "xorg"
Option "XkbModel" "pc104"
Option "XkbLayout" "en_US"
EndSection

I understand that libinput may require udev (eudev)
but I am not sure if it can also use static nodes.

Any advice would be extremely appreciated.

[toc] | [next] | [standalone]

#29650

On Sun, 05 Apr 2020 22:29:49 +0000, Rich wrote:

> 
> If this is true, then udev (and likely eudev as well) allows for static 
> device nodes by an appropriate stanza in an appropriate udev (eudev) 
> configuration file.
> 

I did a test by switching the mouse driver in my xorg.conf
file:

Section "InputDevice"
Identifier "Mouse1"
Driver "libinput"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mouse0"

After re-starting Xorg the mouse was non-functional.
The Xorg.log file showed this:

[ 18281.838] (II) Using input driver 'libinput' for 'Mouse1'
[ 18281.838] (**) Option "CorePointer"
[ 18281.838] (**) Mouse1: always reports core events
[ 18281.838] (**) Option "Device" "/dev/input/mouse0"
[ 18283.869] (EE) libinput bug: udev device never initialized (/dev/input/mouse0)
[ 18283.869] (EE) client bug: Invalid path /dev/input/mouse0
[ 18283.869] (EE) libinput: Mouse1: Failed to create a device for /dev/input/mouse0
[ 18283.869] (EE) PreInit returned 2 for "Mouse1"
[ 18283.869] (II) UnloadModule: "libinput"

So the libinput driver is loaded but since I don't use
udev (eudev) because of static nodes, no device was created
for /dev/input/mouse0, even though the node /dev/input/mouse0
does exist.  (Indeed, I use /dev/input/mouse0 with the legacy
mouse driver.)

I need to somehow create a device for /dev/input/mouse0 before
I start Xorg and then the libinput driver should work.  But
how do I do that?

If I can solve this then I should be able to get both mouse
and keyboard working with libinput using static nodes.

[toc] | [prev] | [next] | [standalone]

#29651

On 06/04/2020 00.17, F Russell wrote:

First, don't set followup-to if you crosspost, it's quite rude, if you 
want a specific news group, then don't crosspost.


> This will leave me in a lurch because I am still using
> the simple keyboard and mouse drivers along with static
> device nodes.  (If it ain't broke don't fix it.)

I did that too back in the 1990's, but Xfree86 already made the changes.

> But I need to plan for the future.
> 
> Is there a way to use the new xorg libinput driver with
> static device nodes?  My kernel is configured with evdev
> and the keyboard and mouse should be accessible though
> /dev/input/event* nodes.  But how do I determine which node?

You don't, you let xorg take care of that for you.

The configuration I use would look something like this in your case:

Section "InputDevice"
  Identifier "system-keyboard"
  Option "XkbRules" "xorg"
  Option "XkbModel" "pc104"
  Option "XkbLayout" "en_US"
EndSection

> I understand that libinput may require udev (eudev)
> but I am not sure if it can also use static nodes.

I have no rules in eudev fro keyboard or mouse.

> Any advice would be extremely appreciated.

Let xorg take care of things dynamically for you.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#29652

On Mon, 06 Apr 2020 01:02:44 -0400, J.O. Aho <user@example.net> wrote:

> Let xorg take care of things dynamically for you.

Agreed, it's pointless mixing old and new software, then complaining that it
doesn't work.

As to this specific question, as usual not enough information has been provided.
What works for a usb keyboard/mouse is not going to work with ones connected using
ps/2 or serial ports. Doesn't matter anyway, since the answer is to only use
software that is compatible.

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#29653

On 06/04/2020 07.32, David W. Hodgins wrote:
> On Mon, 06 Apr 2020 01:02:44 -0400, J.O. Aho <user@example.net> wrote:
> 
>> Let xorg take care of things dynamically for you.
> 
> Agreed, it's pointless mixing old and new software, then complaining 
> that it doesn't work.
>
> What works for a usb keyboard/mouse is not going to work with ones 
> connected using ps/2 or serial ports.
The major issue with ps/2 is that it's not really hotplug, may work if 
you restart xorg, sadly not easy to get a ISA USB card nowadays, but if 
OP has PCI slots in his machine there should still be some PCI USB cards 
on ebay, so he would be able to take a step into to the "future".

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#29654

On 06/04/2020 10.44, J.O. Aho wrote:
> On 06/04/2020 07.32, David W. Hodgins wrote:
>> On Mon, 06 Apr 2020 01:02:44 -0400, J.O. Aho <user@example.net> wrote:
>>
>>> Let xorg take care of things dynamically for you.
>>
>> Agreed, it's pointless mixing old and new software, then complaining 
>> that it doesn't work.
>>
>> What works for a usb keyboard/mouse is not going to work with ones 
>> connected using ps/2 or serial ports.
> The major issue with ps/2 is that it's not really hotplug,

There were warnings in the past to never play with that plug, that there 
could be damage. I have never seen it though, so perhaps only applied to 
some hardware.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#29657

Carlos E.R. wrote:
> On 06/04/2020 10.44, J.O. Aho wrote:
>> On 06/04/2020 07.32, David W. Hodgins wrote:
>>> On Mon, 06 Apr 2020 01:02:44 -0400, J.O. Aho <user@example.net> wrote:
>>>
>>>> Let xorg take care of things dynamically for you.
>>>
>>> Agreed, it's pointless mixing old and new software, then complaining 
>>> that it doesn't work.
>>>
>>> What works for a usb keyboard/mouse is not going to work with ones 
>>> connected using ps/2 or serial ports.
>> The major issue with ps/2 is that it's not really hotplug,
> 
> There were warnings in the past to never play with that plug, that there 
> could be damage. I have never seen it though, so perhaps only applied to 
> some hardware.
> 

A better connector design for PS/2 would help.

If you look at some of the plugs on your computer,
the VCC and GND have longer contacts, and make
contact first. This ensures that power levels
are established first, before logic signals touch.

Pick up a USB flash stick for example, and shine a
flashlight into the barrel. The two outside contacts
are longer than the center contacts. The contact length
must be such, to take into consideration how much the
connector can be tilted off-axis as it captures into
its mate.

You will see a certain amount of hardware on your
computer, uses this concept. In this example, the ground
contacts touch first.

https://multimedia.3m.com/mws/media/333840F/3mtm-serial-adv-tech-attach-connector-ts2108.jpg

    Paul

[toc] | [prev] | [next] | [standalone]

#29678

On 06/04/2020 11.53, Paul wrote:
> Carlos E.R. wrote:
>> On 06/04/2020 10.44, J.O. Aho wrote:
>>> On 06/04/2020 07.32, David W. Hodgins wrote:
>>>> On Mon, 06 Apr 2020 01:02:44 -0400, J.O. Aho <user@example.net> wrote:
>>>>
>>>>> Let xorg take care of things dynamically for you.
>>>>
>>>> Agreed, it's pointless mixing old and new software, then complaining 
>>>> that it doesn't work.
>>>>
>>>> What works for a usb keyboard/mouse is not going to work with ones 
>>>> connected using ps/2 or serial ports.
>>> The major issue with ps/2 is that it's not really hotplug,
>>
>> There were warnings in the past to never play with that plug, that 
>> there could be damage. I have never seen it though, so perhaps only 
>> applied to some hardware.
>>
> 
> A better connector design for PS/2 would help.
> 
> If you look at some of the plugs on your computer,
> the VCC and GND have longer contacts, and make
> contact first. This ensures that power levels
> are established first, before logic signals touch.

Right.


> Pick up a USB flash stick for example, and shine a
> flashlight into the barrel. The two outside contacts
> are longer than the center contacts. The contact length
> must be such, to take into consideration how much the
> connector can be tilted off-axis as it captures into
> its mate.

Yes.


> You will see a certain amount of hardware on your
> computer, uses this concept. In this example, the ground
> contacts touch first.
> 
> https://multimedia.3m.com/mws/media/333840F/3mtm-serial-adv-tech-attach-connector-ts2108.jpg 
> 
> 
>     Paul


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#29658

On 06/04/2020 11.08, Carlos E.R. wrote:
> On 06/04/2020 10.44, J.O. Aho wrote:
>> On 06/04/2020 07.32, David W. Hodgins wrote:
>>> On Mon, 06 Apr 2020 01:02:44 -0400, J.O. Aho <user@example.net> wrote:
>>>
>>>> Let xorg take care of things dynamically for you.
>>>
>>> Agreed, it's pointless mixing old and new software, then complaining 
>>> that it doesn't work.
>>>
>>> What works for a usb keyboard/mouse is not going to work with ones 
>>> connected using ps/2 or serial ports.
>> The major issue with ps/2 is that it's not really hotplug,
> 
> There were warnings in the past to never play with that plug, that there 
> could be damage. I have never seen it though, so perhaps only applied to 
> some hardware.

I did fry something on one computer, PS2 keyboard didn't work, but the 
PS2 mouse worked (it had a unified socket for both keyboard/mouse).

But lucky me I had my first USB keyboard, so I could still use the computer.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#29655

On 06/04/2020 07.02, J.O. Aho wrote:
> On 06/04/2020 00.17, F Russell wrote:
> 
> First, don't set followup-to if you crosspost, it's quite rude, if you 
> want a specific news group, then don't crosspost.

Absolutely.

I missed a lot of the replies till I noticed that they were going to 
another group.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#29660

On Mon, 06 Apr 2020 07:02:44 +0200, J.O. Aho wrote:

> 
> You don't, you let xorg take care of that for you.
> 
> The configuration I use would look something like this in your case:
> 
> Section "InputDevice"
>   Identifier "system-keyboard"
>   Option "XkbRules" "xorg"
>   Option "XkbModel" "pc104"
>   Option "XkbLayout" "en_US"
> EndSection
> 

That looks worth a try, but I can only experiment with the
mouse since if I lose the keyboard I cannot easily terminate X.

I changed the mouse section of xorg.conf to eliminate the
"Device" specifier.  The "Driver" specifier must be there
or X refuses to start:

Section "InputDevice"
Identifier "Mouse1"
Driver "libinput"
#Option "Device" "/dev/input/mouse0"

The udev error is now gone but the mouse still won't
function:

[ 63263.220] (II) Using input driver 'libinput' for 'Mouse1'
[ 63263.220] (**) Option "CorePointer"
[ 63263.220] (**) Mouse1: always reports core events
[ 63263.220] (EE) PreInit returned 2 for "Mouse1"
[ 63263.220] (II) UnloadModule: "libinput"

I need to decipher this "PreInit returned 2" message.

The problem possibly is not with X but with the libinput
driver which somehow interacts with udev (eudev).

Also, I may need to recast the entire xorg.conf file.

This needless nonsense, courtesy of the folks at xorg,
will take some time to figure out.

[toc] | [prev] | [next] | [standalone]

#29662

On 2020-04-06, F Russell <fr@random.info> wrote:
> On Mon, 06 Apr 2020 07:02:44 +0200, J.O. Aho wrote:
>
>> 
>> You don't, you let xorg take care of that for you.
>> 
>> The configuration I use would look something like this in your case:
>> 
>> Section "InputDevice"
>>   Identifier "system-keyboard"
>>   Option "XkbRules" "xorg"
>>   Option "XkbModel" "pc104"
>>   Option "XkbLayout" "en_US"
>> EndSection
>> 
>
> That looks worth a try, but I can only experiment with the
> mouse since if I lose the keyboard I cannot easily terminate X.

Having a second device that can access the command-line can be handy,
it could be a serial terminal, or an ssh session from another
computer, or from an android device.  Another option is the power button,
you can set action for a brief press in some config files somewhere, .

-- 
  Jasen.

[toc] | [prev] | [next] | [standalone]

#29663

F Russell wrote:
> On Mon, 06 Apr 2020 07:02:44 +0200, J.O. Aho wrote:
> 
>> You don't, you let xorg take care of that for you.
>>
>> The configuration I use would look something like this in your case:
>>
>> Section "InputDevice"
>>   Identifier "system-keyboard"
>>   Option "XkbRules" "xorg"
>>   Option "XkbModel" "pc104"
>>   Option "XkbLayout" "en_US"
>> EndSection
>>
> 
> That looks worth a try, but I can only experiment with the
> mouse since if I lose the keyboard I cannot easily terminate X.
> 
> I changed the mouse section of xorg.conf to eliminate the
> "Device" specifier.  The "Driver" specifier must be there
> or X refuses to start:
> 
> Section "InputDevice"
> Identifier "Mouse1"
> Driver "libinput"
> #Option "Device" "/dev/input/mouse0"
> 
> The udev error is now gone but the mouse still won't
> function:
> 
> [ 63263.220] (II) Using input driver 'libinput' for 'Mouse1'
> [ 63263.220] (**) Option "CorePointer"
> [ 63263.220] (**) Mouse1: always reports core events
> [ 63263.220] (EE) PreInit returned 2 for "Mouse1"
> [ 63263.220] (II) UnloadModule: "libinput"
> 
> I need to decipher this "PreInit returned 2" message.
> 
> The problem possibly is not with X but with the libinput
> driver which somehow interacts with udev (eudev).
> 
> Also, I may need to recast the entire xorg.conf file.
> 
> This needless nonsense, courtesy of the folks at xorg,
> will take some time to figure out.
> 

Out of curiosity, have you ever relied on the scripts
that come with the proprietary driver packages, to
generate an xorg.conf for you ?

This doesn't guarantee a thing, except to show an
alternative file for examination.

For example, some selected snipped parts from a previous effort.

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 256.53  (buildmeister@builder101)  Fri Aug 27 21:34:01 PDT 2010

Section "InputDevice"
     # generated from default
     Identifier     "Mouse0"
     Driver         "mouse"
     Option         "Protocol" "auto"
     Option         "Device" "/dev/psaux"
     Option         "Emulate3Buttons" "no"
     Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
     # generated from default
     Identifier     "Keyboard0"
     Driver         "kbd"
EndSection

I believe ATI/AMD had a script onboard their package
too, but I don't know what the name of it might be.

OK, according to this, it was "aticonfig".

https://wiki.archlinux.org/index.php/AMD_Catalyst

I used the generated file above, as part of making an xorg.conf
that worked properly in a (partially broken) VM environment. There
is one hosting software, where only 16 bit Xorg works out. (Not
enough virtual "pixel clock rate" for reasonable 24 bit operation.)

    Paul

[toc] | [prev] | [next] | [standalone]

#29666

On Mon, 06 Apr 2020 08:05:48 -0400, Paul wrote:

> 
> have you ever relied on the scripts
> that come with the proprietary driver packages, to
> generate an xorg.conf for you ?
> 

I don't think that the problem is with xorg but rather
with the libinput library.

The xorg libinput driver depends on the libinput library
(a separate package), which in turn depends on eudev.

But even when I start eudev as a daemon, I get nothing
from this command:

libinput list-devices

This command should list all devices recognized by libinput
but shows nothing.  Consequently when I start X I get the
error that the device is not initialized.

Thus I need to figure out how to get the libinput libraries
to recognize the keyboard and mouse.

[toc] | [prev] | [next] | [standalone]

#29659

On 06/04/2020 13.00, F Russell wrote:


> The only lasting solution is to tell the GNU/Linux developers
> to kiss off and move to FreeBSD and that is something that
> I am seriously considering at this point.

You know you will have the same xorg and devd (instead of eudev), so 
your life will be as fucked up with BSD as with Linux. Maybe you should 
be a man and move forward.


> The Linux kernel still has options to suit a variety of
> purposes and preferences.  But user space software, like
> Xorg, are becoming more and more circumscribed, and as
> a consequence, are dragging the kernel into the same shallow
> pit.

Xorg has little to do with the Linux kernel and on to of that, it's not 
even a Linux application but an Unix application that can run on Linux.

You can always voice your opinion at freenode #xorg or write to the 
board members.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#29661

On Mon, 06 Apr 2020 13:24:25 +0200, J.O. Aho wrote:

> Maybe you should 
> be a man and move forward.
> 

That's usually the only technical solution that is offered.

Yet no one can adequately explain how replacing a fool-proof
and simplistic method with bloated complexity is "moving forward."

Some people still prefer to shave with a straight razor.  This
action by xorg is like suddenly mandating that only electric
IOT shavers will henceforth be permitted.

>
> You can always voice your opinion at freenode #xorg or write to the 
> board members.
>

If people with the character and integrity of Linus Torvalds
were on the board that may be a good idea.  But xorg is nothing
but arrogant buffoons with the attitude of "our way or the highway."

>
> Xorg has little to do with the Linux kernel
>

Soon, in order to use Xorg, a certain kernel configuration
will be absolutely required.  This is my point that Xorg
is dragging everything into their narrow pit.

[toc] | [prev] | [next] | [standalone]

#29667

On 06/04/2020 13.41, F Russell wrote:
> On Mon, 06 Apr 2020 13:24:25 +0200, J.O. Aho wrote:
> 
>> Maybe you should
>> be a man and move forward.
>>
> 
> That's usually the only technical solution that is offered.
> 
> Yet no one can adequately explain how replacing a fool-proof
> and simplistic method with bloated complexity is "moving forward."
> 
> Some people still prefer to shave with a straight razor.  This
> action by xorg is like suddenly mandating that only electric
> IOT shavers will henceforth be permitted.

I remember in the time of XFree86 when you needed to use those event 
devices in the config, the drawback was when USB keyboards appeared, 
they tended to get a new event device id each time you re-plugged them, 
but lucky me, XFree86 had fixed that and you didn't have to configure it 
anymore. This was a good think when my mouse middle button broke, all I 
had to do was disconnect the old mouse and plug in the new, no need to 
restart X11. Xorg just keeps on evolving to make it simpler for the user.

>>
>> You can always voice your opinion at freenode #xorg or write to the
>> board members.
>>
> 
> If people with the character and integrity of Linus Torvalds
> were on the board that may be a good idea.  But xorg is nothing
> but arrogant buffoons with the attitude of "our way or the highway."

You can always for of Xorg the same manner as they forked of XFree86.


>> Xorg has little to do with the Linux kernel
>>
> Soon, in order to use Xorg, a certain kernel configuration
> will be absolutely required.  This is my point that Xorg
> is dragging everything into their narrow pit.

Will not happen, Xorg is a multi platform, not like RedHat's Gnome3+.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#29669

On Mon, 06 Apr 2020 15:53:33 +0200, J.O. Aho wrote:

> 
> they tended to get a new event device id each time you re-plugged them, 
> 

That is the general behavior for all USB devices.

But, other than for exceptional circumstances, workstation keyboard
or mouse are not unplugged and replugged.  They are effectively
permanent attachments.

[toc] | [prev] | [next] | [standalone]

#29670

In comp.os.linux.misc F Russell <fr@random.info> wrote:
> On Mon, 06 Apr 2020 15:53:33 +0200, J.O. Aho wrote:
> 
>> 
>> they tended to get a new event device id each time you re-plugged them, 
>> 
> 
> That is the general behavior for all USB devices.
> 
> But, other than for exceptional circumstances, workstation keyboard
> or mouse are not unplugged and replugged.  They are effectively
> permanent attachments.

But because they *can* be unplugged, the software has to handle the 
case when they are unplugged.  Because while you might never unplug 
them, someone, somewhere, will unplug/replug them.

And for an example where they are often unplugged, some USB KVM 
switches operate to change input devices by logically "unplugging" and 
"replugging" the USB keyboard/mouse among the plural machines to which 
they connect.

[toc] | [prev] | [next] | [standalone]

#29671

["Followup-To:" header set to comp.os.linux.misc.]
On 2020-04-06, Rich <rich@example.invalid> wrote:
> In comp.os.linux.misc F Russell <fr@random.info> wrote:
>> On Mon, 06 Apr 2020 15:53:33 +0200, J.O. Aho wrote:
>> 
>>> 
>>> they tended to get a new event device id each time you re-plugged them, 
>>> 
>> 
>> That is the general behavior for all USB devices.
>> 
>> But, other than for exceptional circumstances, workstation keyboard
>> or mouse are not unplugged and replugged.  They are effectively
>> permanent attachments.
>
> But because they *can* be unplugged, the software has to handle the 
> case when they are unplugged.  Because while you might never unplug 
> them, someone, somewhere, will unplug/replug them.

True. My mouse has a bit a broken cable and gets replugged very often.
Which is not recognisable since it happens very quickly.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web