Xorg Libinput with Static Nodes

[F Russell]

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.

[Rich]

In comp.os.linux.misc F Russell <f...@random.info> wrote:
> I understand that libinput may require udev (eudev)
> but I am not sure if it can also use static nodes.

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.

Note, you requested followups to alt.os.linux, but I'm not currently
subscribed there, so unless you continue to cross post I won't see any
reply from you.

[F Russell]

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.

[Dan Espen]

F Russell <f...@random.info> writes:

> 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.

Whatever you have that is using static device nodes
really is broken.
Plan for a future without static device nodes,
your time will be better spent.

--
Dan Espen

[Ned Latham]

F Russell wrote:
>
> 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.)

You could apply that maxim to your system. The older your H/W
gets, the less likely it is to benefit from system upgrades.

----snip----

[Rich]

In comp.os.linux.misc F Russell <f...@random.info> wrote:

> 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 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?

Look at the manual page for the 'mknod' command.

[F Russell]

On Sun, 05 Apr 2020 21:45:11 -0400, Dan Espen wrote:

>
> Whatever you have that is using static device nodes
> really is broken.
>

How so?

A static node is nothing more than a dynamic node that
is created in advance. A system can boot and dynamically
create a node or the node can already be there. There
is no difference.

IOW, why have udev (eudev) create the nodes when they
can be created beforehand? There is no difference.

But this is all preaching. It does not contribute
to the solution of my problem.

[F Russell]

On Sun, 05 Apr 2020 21:14:52 -0500, Ned Latham wrote:

>
> You could apply that maxim to your system. The older your H/W
> gets, the less likely it is to benefit from system upgrades.
>

Again, more preaching and no problem solving.

The kernel sends a notice to udev (eudev) that a device
has been detected. Udev (eudev) then reads some files (rules)
and then creates a device node.

Static nodes just remove the middleman by already having
nodes in place. There is no difference, or at least ther
should be no difference.

[F Russell]

On Mon, 06 Apr 2020 02:41:06 +0000, Rich wrote:

>>
>> 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?
>
> Look at the manual page for the 'mknod' command.
>

As I indicated, the device node /dev/input/mouse0 already
exists. Yet the xorg libinput driver seems to report that
it is not initialized or created. Why does it do this?

It could be relying on udev (eudev) but I don't know.

All the information about devices is in the /sys directory.
Udev (eudev) merely accesses this information and all the
/sys information matches my static device nodes. They work
with the legacy drivers but they don't work with libinput.

[Ned Latham]

F Russell wrote:
> Ned Latham wrote:
> >
> > You could apply that maxim to your system. The older your H/W
> > gets, the less likely it is to benefit from system upgrades.
>
> Again, more preaching and no problem solving.

Wrong. Suggestiung a solution. One which, moreover, requires
*no* effort.

----snip----

[J.O. Aho]

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

[David W. Hodgins]

On Mon, 06 Apr 2020 01:02:44 -0400, J.O. Aho <us...@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 dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.

[J.O. Aho]

On 06/04/2020 07.32, David W. Hodgins wrote:
> On Mon, 06 Apr 2020 01:02:44 -0400, J.O. Aho <us...@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

[Carlos E.R.]

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 <us...@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.

[Carlos E.R.]

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.

[Paul]

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

[F Russell]

On Sun, 05 Apr 2020 22:57:14 -0500, Ned Latham wrote:

>
> Wrong. Suggestiung a solution. One which, moreover, requires
> *no* effort.
>

My system, composed of the latest Xeon W hardware, works
just fine and has been working just fine and should continue
to work just fine into the indefinite future.

But the sudden changes introduced by xorg to eliminate
two very functional, straightforward, and very simple
drivers has now necessitated that I reconfigure and rework
major portions of the system just to get a usable keyboard
and mouse.

I knew this was coming. Simplicity has gone out the window
in favor of the absurd and useless complexity of systemd
and related components. Udev (eudev) is no longer just
an option but now an absolute requirement.

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.

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.

[J.O. Aho]

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

[J.O. Aho]

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

[F Russell]

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.

[F Russell]

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.

[Jasen Betts]

On 2020-04-06, F Russell <f...@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.

[Paul]

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

[F Russell]

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

>

> 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.
>

Doesn't FreeBSD also use static nodes? I don't know yet because
I have not researched.

But the thing about udev (eudev) is that it should be totally
optional but it is not, and this is a serious design flaw.

Consider the similar management service called avahi. The
purpose of avahi is to determine what is on the local network,
but some people (imagine that!) actually already know what is
on their local network. Therefore, such people can opt out
of using avahi. Wow! How's that for a concept!

Udev (eudev) should be similarly optional but it's not and
this is a serious design failure.

Such a serious design flaw cannot be so easily dismissed by
simply saying that one has to "move forward" or "keep up
with the times." A flaw is not progress.

[Ned Latham]

F Russell wrote:
> Ned Latham wrote:
> >

> > Wrong. Suggesting a solution. One which, moreover, requires

> > *no* effort.
>
> My system, composed of the latest Xeon W hardware,

Nice!

> works just fine and has been working just fine and should continue
> to work just fine into the indefinite future.

Yep.

> But the sudden changes introduced by xorg to eliminate
> two very functional, straightforward, and very simple
> drivers has now necessitated that I reconfigure and rework
> major portions of the system just to get a usable keyboard
> and mouse.

I presume all was well before your latest system upgrade? Would
reverting solve that problem without introducing another?

> I knew this was coming.

Yes, I have a problem impending with versionitis too. C++, mine.
My intention is that if I can't resolve it without difficulty
I'll dump C++.

> Simplicity has gone out the window
> in favor of the absurd and useless complexity of systemd
> and related components. Udev (eudev) is no longer just
> an option but now an absolute requirement.
>
> 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.

Another possibility lies in moving to a distro that doesn't use
systemd. Wikipedia has a listing of Linux distributions that do
and don't use it. It mentions a fork of Debian called Devuan,
developed purely for the purpose of avoiding systemd.

There is also
https://www.osnews.com/story/130043/linux-distributions-without-systemd/

I use Slackware. SysVinit. Been using it since 1999. It's a
very stable distro, well balanced, secure, and for me, free
of problems (except that damned C++ bloat).

Check out http://www.slackware.com/

And for additional S/W, https://slackbuilds.org/repository/

> 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.

A rapid turnover of versions is pretty much necessary during the
infancy of an industry, but not once it's reached a functioning
level of maturity. Then, it becomes versionitis, a Big Business
disease, similar to planned obsolescence.

[F Russell]

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.

[F Russell]

On Mon, 06 Apr 2020 07:24:10 -0500, Ned Latham wrote:

>
> I presume all was well before your latest system upgrade? Would
> reverting solve that problem without introducing another?
>

Everything works very well right now. I am just considering
the time in the near future when Xorg will eliminate the legacy
keyboard and mouse input drivers and replace them with libinput.

[J.O. Aho]

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

[Ned Latham]

Oh, I misunderstood. Sorry.

[J.O. Aho]

On 06/04/2020 14.19, F Russell wrote:
> On Mon, 06 Apr 2020 13:24:25 +0200, J.O. Aho wrote:
>
>>
>> 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.
>>
>
> Doesn't FreeBSD also use static nodes? I don't know yet because
> I have not researched.

I guess you can write dome devd rules to handle that, it's quite long
ago I run BSD, back in the days when a computer was good hardware.

> But the thing about udev (eudev) is that it should be totally
> optional but it is not, and this is a serious design flaw.

There was other tools befoe udev/eudev like mdev (you can not run the
latest version of evdev with it), you had also HAL but both Linux and
FreeBSD migrated away from HAL around 2008, think FreeBSD may have been
faster as in Linux you had a time with udev+HAL as companion tools,
before udev could replace HAL completely.

> Consider the similar management service called avahi. The
> purpose of avahi is to determine what is on the local network,
> but some people (imagine that!) actually already know what is
> on their local network. Therefore, such people can opt out
> of using avahi. Wow! How's that for a concept!
>
> Udev (eudev) should be similarly optional but it's not and
> this is a serious design failure.

They are, but you are limited in what applications you can use, as they
may have dependencies to udev in the same way as desktop environments
had dependencies to HAL.

I guess you think it's silly to be able to automount a usb storage that
you plugin.

> Such a serious design flaw cannot be so easily dismissed by
> simply saying that one has to "move forward" or "keep up
> with the times." A flaw is not progress.

You can of course stay back with a vulnerable xorg version, no one will
stop you, just look around you there are still people using windows xp
and windows 10.

--

//Aho

[F Russell]

On Mon, 06 Apr 2020 13:45:41 +0000, F Russell wrote:

>
> libinput list-devices
>
> This command should list all devices recognized by libinput
> but shows nothing.
>

I just did an strace on this command:

openat(AT_FDCWD, "/run/udev/data/c13:67", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
readlink("/sys/devices/virtual/input/mice", 0x7ffeeb12cb80, 1024) = -1 EINVAL (Invalid argument)
stat("/sys/devices/virtual/input/mice/uevent", {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
epoll_wait(3, [], 32, 0) = 0
close(5) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 5, NULL) = -1 EBADF (Bad file descriptor)
epoll_ctl(3, EPOLL_CTL_DEL, 4, NULL) = 0
close(4) = 0
close(3) = 0
exit_group(0) = ?
+++ exited with 0 +++

Is this a normal termination or is it a fault?

If anyone is using libinput could you possibly post the strace
output, as a file attachment, using this command:

strace libinput list-devices

[F Russell]

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.

[Rich]

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.

[Fenris]

["Followup-To:" header set to comp.os.linux.misc.]

On 2020-04-06, Rich <ri...@example.invalid> wrote:
> In comp.os.linux.misc F Russell <f...@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.

[F Russell]

On Mon, 06 Apr 2020 14:10:04 +0000, F Russell wrote:

>
> openat(AT_FDCWD, "/run/udev/data/c13:67", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>

I have a hunch as to what is happening.

Libinput is looking for a file in /run/udev/data called "c13:67"

These numbers represent the major and minor numbers for a character
device node /dev/input/event3. The node exists but the file in
/run/dev/data does not exist.

Libinput uses files in /run/udev/data, which are established
by eudev, to get the parameters which it then passes to Xorg.
But the file does not exist.

Can someone post the content of these "cXX:XX" files in their
/run/udev/data directory? If I know the format I can create
them myself.

[F Russell]

On Mon, 06 Apr 2020 16:09:52 +0200, J.O. Aho wrote:

>
> I guess you think it's silly to be able to automount a usb storage that
> you plugin.
>

Automatic mounting can be accomplished by any software
that is written for the purpose.

What I find "silly" (actually insidious) is the trend
toward a single daemon that constantly "listens" not
just for plug-in events but for all system events.

A single point of control has great potential for
abuse, as we see with Microsoft.

[DecadentLinux...@decadence.org]

F Russell <f...@random.info> wrote in news:r6f2...@news4.newsguy.com:

Free and or Open BSD it is!

My acellerated Quadro gets driven fine under BSD. What more could I
want than to do CAD on a machine that works without heavy massage
sessions.

I still have to learn simple things like how to setup termcap and
such. One step at a time.

[J.O. Aho]

KVM Switch or in my case I had a headless machine without keyboard, but
sometime things happen when I needed a keyboard, so I just took the one
from the desktop machine plugged it in to the headless machine and then
back to the desktop, was a pita to restart X11 to be able to use the
keyboard once again. Things was even worse on a laptop when you wanted
to use an external keyboard... so I rather have the dependency to udev
which I can replace with eudev.

--

//Aho

[Carlos E.R.]

cer@Telcontar:~> file /run/udev/data/c13\:67
/run/udev/data/c13:67: ASCII text
cer@Telcontar:~>

cer@Telcontar:~> cat /run/udev/data/c13\:67
I:10800864
E:ID_INPUT=1
E:ID_INPUT_SWITCH=1
E:ID_PATH=pci-0000:27:00.1
E:ID_PATH_TAG=pci-0000_27_00_1
E:LIBINPUT_DEVICE_GROUP=0/0/0:ALSA
G:power-switch
cer@Telcontar:~>

--
Cheers, Carlos.

[F Russell]

On Mon, 06 Apr 2020 19:05:01 +0200, Carlos E.R. wrote:

>
> cer@Telcontar:~> cat /run/udev/data/c13\:67
> I:10800864
> E:ID_INPUT=1
> E:ID_INPUT_SWITCH=1
> E:ID_PATH=pci-0000:27:00.1
> E:ID_PATH_TAG=pci-0000_27_00_1
> E:LIBINPUT_DEVICE_GROUP=0/0/0:ALSA
> G:power-switch
> cer@Telcontar:~>
>

Thanks much for this.

Libinput must use these files, which are set up by
eudev, to get the device parameters and then pass
those parameters on to xorg libinput. If the files
are not there, then the "not initialized" error
is shown by xorg.

Unfortunately, I do not understand the format.
I suspected that they might mirror the contents
of /sys/devices/... but they don't.

Also, on your machine the character device with
major 13 and minor 67 (/dev/input/event3) seems
to be mapped to an alsa device.

I will next boot with a Linux LiveUSB and see
what the /run/udev/data/* files show on my machine.
Since my hardware configuration does not change
I could maybe use that info for my system.


Thanks again for taking the time and trouble.

[F Russell]

On Mon, 06 Apr 2020 14:58:11 +0000, DecadentLinuxUserNumeroUno wrote:

>>
> Free and or Open BSD it is!
>

Linux seems like it's getting closer and closer each day
to the spirit of Microsoft Windows: increasing centralization,
lack of choice and control, and a stupefied user base
that is oblivious to it all.

[Carlos E.R.]

You can always create your own system with your own choices.

Most of us, we are happy to choose a distro and use it as it comes. It
simply works, and we can use our time in things we need or choose to.


--
Cheers, Carlos.

[Carlos E.R.]

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 <us...@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.

[F Russell]

On Mon, 06 Apr 2020 17:25:41 +0000, F Russell wrote:

>
> I will next boot with a Linux LiveUSB and see
> what the /run/udev/data/* files show on my machine.
> Since my hardware configuration does not change
> I could maybe use that info for my system.
>

It worked! I booted up with a LiveUSB (PCLinuxOS)
and copied the /run/udev/data files to my system.

Now, even though I do NOT use that ridiculous monstrosity
known as udev (eudev), the libinput driver is fooled
into thinking that udev (eudev) is present and it reads
the info from /run/udev/data. Xorg will start and
the mouse/keyboard will function with the newfangled
libinput.

This saves me a TON of trouble. I would have had to
re-configure and re-compile the kernel for a RAM disk
and install all the other other assorted nonsense that
is required for udev (eudev).

"Modern" Linux is a joke. It has exchanged the smooth
simplicity of static devices for the absurd jumble of
dynamic device managers.

I don't need a HUMONGOUS hardware database and the associated
software daemons to tell me that I have an optical mouse
attached to my machine. Only a lunatic idiot would prefer
udev (eudev).

For those who cannot build from scratch let them have
the "turnkey" distros.

But for the builders like myself, keep is simple stupid.

The files that I copied into /run/udev/data will be stable.
For the life of the machine they will NOT change. IOW,
they are essentially STATIC NODES, but yet they must be redetermined
again and again with every reboot. So why be stupid?
Just use static nodes from the beginning and toss udev (eudev)
into the trash can.

In "modern" Linux, the lunatics have taken over the asylum.

[DecadentLinux...@decadence.org]

"Carlos E.R." <robin_...@es.invalid> wrote in
news:hehslg-...@Telcontar.valinor:

In every case, including the one he mentioned and including the one
I mentioned.

Most of us try not to claim to know what most of us knows or "are
happy" with.

[Melzzzzz]

Only lunatic idiot would botther with such things...
no tanks I did my homework in 90es...

--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala