Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[gentoo-user] X11 without udev/eudev
228 views
Skip to first unread message
ka...@aspodata.se
Aug 21, 2021, 4:20:03 PM8/21/21
to
With the demise of xf86-input-mouse and xf86-input-keyboard,
xf86-input-libinput is put forward as a replacement.
But it (or rather libinput) has udev as a hard dependency.
I have a ps2 keyboard and a 3-button serial mouse, so there is frankly
no use for udev here, nor would it help anything except possible to mess
up my preset dev directory. Also I have sys-fs/static, even if I install
udev, it woun't start, and I don't need yet another deamon running
doing nothing for me.
Is there possible to resurrect the old drivers ?
Or is there another way to solve this ?
Regards,
/Karl Hammar
xf86-input-libinput is put forward as a replacement.
But it (or rather libinput) has udev as a hard dependency.
I have a ps2 keyboard and a 3-button serial mouse, so there is frankly
no use for udev here, nor would it help anything except possible to mess
up my preset dev directory. Also I have sys-fs/static, even if I install
udev, it woun't start, and I don't need yet another deamon running
doing nothing for me.
Is there possible to resurrect the old drivers ?
Or is there another way to solve this ?
Regards,
/Karl Hammar
antlists
Aug 21, 2021, 5:10:03 PM8/21/21
to
On 21/08/2021 21:17, ka...@aspodata.se wrote:
> Is there possible to resurrect the old drivers ?
> Or is there another way to solve this ?
Put in a bug report?
> Is there possible to resurrect the old drivers ?
> Or is there another way to solve this ?
Cheers,
Wol
Vitor Hugo Nunes dos Santos
Aug 21, 2021, 6:00:04 PM8/21/21
to
This should have some of the info you need
https://wiki.gentoo.org/wiki/Old_Fashioned_Gentoo_Install
Best regards,
Vitor Hugo
ka...@aspodata.se
Aug 21, 2021, 6:40:04 PM8/21/21
to
Vitor Hugo:
...
year somehow just claims I have to have a lot of (for me) useless
processes.
I have tried the overlay route, but since some time I get:
* ERROR: x11-base/xorg-server-1.18.4::aspo failed (depend phase):
* xorg-2.eclass could not be found by inherit()
*
* Call stack:
* ebuild.sh, line 609: Called source '/home/local/portage/x11-base/xorg-server/xorg-server-1.18.4.ebuild'
* xorg-server-1.18.4.ebuild, line 8: Called inherit 'xorg-2' 'multilib' 'versionator' 'flag-o-matic'
* ebuild.sh, line 290: Called die
* The specific snippet of code:
* [[ -z ${location} ]] && die "${1}.eclass could not be found by inherit()"
*
Regards,
/Karl Hammar
...
> This should have some of the info you need
> https://wiki.gentoo.org/wiki/Old_Fashioned_Gentoo_Install
Well, I already have such a system, but developments since last
> https://wiki.gentoo.org/wiki/Old_Fashioned_Gentoo_Install
year somehow just claims I have to have a lot of (for me) useless
processes.
I have tried the overlay route, but since some time I get:
* ERROR: x11-base/xorg-server-1.18.4::aspo failed (depend phase):
* xorg-2.eclass could not be found by inherit()
*
* Call stack:
* ebuild.sh, line 609: Called source '/home/local/portage/x11-base/xorg-server/xorg-server-1.18.4.ebuild'
* xorg-server-1.18.4.ebuild, line 8: Called inherit 'xorg-2' 'multilib' 'versionator' 'flag-o-matic'
* ebuild.sh, line 290: Called die
* The specific snippet of code:
* [[ -z ${location} ]] && die "${1}.eclass could not be found by inherit()"
*
Regards,
/Karl Hammar
ka...@aspodata.se
Aug 21, 2021, 6:40:04 PM8/21/21
to
Wol:
I don't think libinput maintainers would care.
https://wayland.freedesktop.org/libinput/doc/latest/what-is-libinput.html
plainly says:
libinput is an input stack for processes that need to provide events
from commonly used input devices.
and serial mice isn't common any longer, and udev has never (from what I
know) cared about serial mice.
Regards,
/Karl Hammar
https://wayland.freedesktop.org/libinput/doc/latest/what-is-libinput.html
plainly says:
libinput is an input stack for processes that need to provide events
from commonly used input devices.
and serial mice isn't common any longer, and udev has never (from what I
know) cared about serial mice.
Regards,
/Karl Hammar
Neil Bothwick
Aug 21, 2021, 6:50:04 PM8/21/21
to
On Sun, 22 Aug 2021 00:34:32 +0200 (CEST), ka...@aspodata.se wrote:
> > This should have some of the info you need
> > https://wiki.gentoo.org/wiki/Old_Fashioned_Gentoo_Install
>
> Well, I already have such a system, but developments since last
> year somehow just claims I have to have a lot of (for me) useless
> processes.
>
> I have tried the overlay route, but since some time I get:
>
> * ERROR: x11-base/xorg-server-1.18.4::aspo failed (depend phase):
> * xorg-2.eclass could not be found by inherit()
> *
You need to grab xorg-2.eclass from the git history and put it in your
> > This should have some of the info you need
> > https://wiki.gentoo.org/wiki/Old_Fashioned_Gentoo_Install
>
> Well, I already have such a system, but developments since last
> year somehow just claims I have to have a lot of (for me) useless
> processes.
>
> I have tried the overlay route, but since some time I get:
>
> * ERROR: x11-base/xorg-server-1.18.4::aspo failed (depend phase):
> * xorg-2.eclass could not be found by inherit()
> *
overlay. Be prepared to repeat this process with other files.
--
Neil Bothwick
"I laugh in the face of danger, then I hide until it goes away"
Anna “CyberTailor”
Aug 21, 2021, 8:00:03 PM8/21/21
to
git clone https://anongit.gentoo.org/git/repo/gentoo.git && cd gentoo
git log -p -- x11-drivers/xf86-input-keyboard
git checkout commit_id
Copy to your local overlay
> Or is there another way to solve this ?
Try libudev-zero (install it and add udev/libudev virtuals to
package.provided)
https://github.com/illiliti/libudev-zero
git log -p -- x11-drivers/xf86-input-keyboard
git checkout commit_id
Copy to your local overlay
> Or is there another way to solve this ?
package.provided)
https://github.com/illiliti/libudev-zero
Mart Raudsepp
Aug 22, 2021, 7:10:03 AM8/22/21
to
Ühel kenal päeval, L, 21.08.2021 kell 23:45, kirjutas Neil Bothwick:
> On Sun, 22 Aug 2021 00:34:32 +0200 (CEST), ka...@aspodata.se wrote:
>
> > > This should have some of the info you need
> > > https://wiki.gentoo.org/wiki/Old_Fashioned_Gentoo_Install
> >
> > Well, I already have such a system, but developments since last
> > year somehow just claims I have to have a lot of (for me) useless
> > processes.
> >
> > I have tried the overlay route, but since some time I get:
> >
> > * ERROR: x11-base/xorg-server-1.18.4::aspo failed (depend phase):
> > * xorg-2.eclass could not be found by inherit()
> > *
>
> You need to grab xorg-2.eclass from the git history and put it in
> your
> overlay. Be prepared to repeat this process with other files.
Also be prepared for all the known security vulnerabilities you
> On Sun, 22 Aug 2021 00:34:32 +0200 (CEST), ka...@aspodata.se wrote:
>
> > > This should have some of the info you need
> > > https://wiki.gentoo.org/wiki/Old_Fashioned_Gentoo_Install
> >
> > Well, I already have such a system, but developments since last
> > year somehow just claims I have to have a lot of (for me) useless
> > processes.
> >
> > I have tried the overlay route, but since some time I get:
> >
> > * ERROR: x11-base/xorg-server-1.18.4::aspo failed (depend phase):
> > * xorg-2.eclass could not be found by inherit()
> > *
>
> You need to grab xorg-2.eclass from the git history and put it in
> your
> overlay. Be prepared to repeat this process with other files.
reintroduce by installing a heavily outdated xorg-server with multiple
known vulnerabilities.
Mart
ka...@aspodata.se
Aug 22, 2021, 4:40:03 PM8/22/21
to
Neil Bothwick:
...
Regards,
/Karl Hammar
...
> You need to grab xorg-2.eclass from the git history and put it in your
> overlay. Be prepared to repeat this process with other files.
Thanks, found them.
> overlay. Be prepared to repeat this process with other files.
Regards,
/Karl Hammar
ka...@aspodata.se
Aug 22, 2021, 4:40:04 PM8/22/21
to
Mart:
...
I don't reintroduce them, I just keep them.
Also, I had upgraded it if it wasn't for the udev dependancy.
If you have a solution without udev, please tell me.
Regards,
/Karl Hammar
...
> Also be prepared for all the known security vulnerabilities you
> reintroduce by installing a heavily outdated xorg-server with multiple
> known vulnerabilities.
...
> reintroduce by installing a heavily outdated xorg-server with multiple
> known vulnerabilities.
I don't reintroduce them, I just keep them.
Also, I had upgraded it if it wasn't for the udev dependancy.
If you have a solution without udev, please tell me.
Regards,
/Karl Hammar
ka...@aspodata.se
Aug 22, 2021, 4:40:04 PM8/22/21
to
Anna:
> > Or is there another way to solve this ?
> Try libudev-zero (install it and add udev/libudev virtuals to
> package.provided)
> https://github.com/illiliti/libudev-zero
I'll be looking into that, but on some level, why should I be forced to
go around udev. Can't programs be compiled without udev today...
Udev should be an optional deamon, utilized when the local
administrator decides to do so. I don't want things to automatically
pop up unless I say so.
Regards,
/Karl Hammar
> On 2021-08-21 22:17, ka...@aspodata.se wrote:
> > Is there possible to resurrect the old drivers ?
> git clone https://anongit.gentoo.org/git/repo/gentoo.git && cd gentoo
> git log -p -- x11-drivers/xf86-input-keyboard
> git checkout commit_id
>
> Copy to your local overlay
Thanks Anna, done so.
> > Is there possible to resurrect the old drivers ?
> git clone https://anongit.gentoo.org/git/repo/gentoo.git && cd gentoo
> git log -p -- x11-drivers/xf86-input-keyboard
> git checkout commit_id
>
> Copy to your local overlay
> > Or is there another way to solve this ?
> Try libudev-zero (install it and add udev/libudev virtuals to
> package.provided)
> https://github.com/illiliti/libudev-zero
go around udev. Can't programs be compiled without udev today...
Udev should be an optional deamon, utilized when the local
administrator decides to do so. I don't want things to automatically
pop up unless I say so.
Regards,
/Karl Hammar
Canek Peláez Valdés
Aug 22, 2021, 6:00:08 PM8/22/21
to
On Sun, Aug 22, 2021 at 3:32 PM <ka...@aspodata.se> wrote:
[...]
I'll be looking into that, but on some level, why should I be forced to
go around udev. Can't programs be compiled without udev today...
Yes, they can, if you (or someone else) write the necessary code, debug it, maintain it and keep it up to date and fix vulnerabilities and other errors that inevitably will appear, as it does with every piece of software.
Udev should be an optional deamon, utilized when the local administrator decides to do so.
Wrong: the use of udev is to be decided by the developers of the code that uses it. If you don't like it, then you write your own. The code is free and open.
Udev solves a very real problem, because most modern PCs have dynamic hardware; we connect and disconnect multiple devices from it all the time, and the vast majority of users prefer it when it simply works automagically. Moreover, it *also* works with static hardware, so it hits two birds with one stone.
You want developers to write code that only benefits the simplest and most boring case: a PC that never changes hardware. Any sane developer will obviously prefer to depend on udev, which solves every case and it has the most users (and therefore feedback for detecting and correcting bugs, and also to ask for new features and capabilities).
I don't want things to automatically pop up unless I say so.
Then write yourself the corresponding software, or pay someone to do it. Otherwise, complaining (while cathartic and the preferred hobby of most of the internet) is completely useless.
Regards.
--
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México
antlists
Aug 22, 2021, 7:20:03 PM8/22/21
to
On 22/08/2021 22:59, Canek Peláez Valdés wrote:
> On Sun, Aug 22, 2021 at 3:32 PM <ka...@aspodata.se
> <mailto:ka...@aspodata.se>> wrote:
> [...]
>
> I'll be looking into that, but on some level, why should I be forced to
> go around udev. Can't programs be compiled without udev today...
>
>
> Yes, they can, if you (or someone else) write the necessary code, debug
> it, maintain it and keep it up to date and fix vulnerabilities and other
> errors that inevitably will appear, as it does with every piece of software.
What you're missing, is that this code IS NOT USED.
> On Sun, Aug 22, 2021 at 3:32 PM <ka...@aspodata.se
> <mailto:ka...@aspodata.se>> wrote:
> [...]
>
> I'll be looking into that, but on some level, why should I be forced to
> go around udev. Can't programs be compiled without udev today...
>
>
> Yes, they can, if you (or someone else) write the necessary code, debug
> it, maintain it and keep it up to date and fix vulnerabilities and other
> errors that inevitably will appear, as it does with every piece of software.
The OP wants to delete a load of code from his system precisely to
ELIMINATE vulnerabilities. If the code ain't there, it don't need fixing.
Yes I take your point, but bloat is bloat, and bloat is a liability.
Cheers,
Wol
Rich Freeman
Aug 22, 2021, 7:40:04 PM8/22/21
to
commitment for you to maintain your own private fork of the software.
Still, somebody has to do the work, and since the number of people who
don't have udev installed is pretty small, chances are it won't be
somebody else. Of course, you can release your fork as FOSS so that
others can benefit from it.
Keep in mind that even just removing code does incur the risk of
making mistakes, and at some point maintaining a fork that almost
nobody uses also has some risk to it. Don't really want to get into a
completely hypothetical argument about which is worse - obviously the
devil is in the details. This is likely why upstreams are mostly not
interested in supporting building without a requirement of udev.
--
Rich
Canek Peláez Valdés
Aug 22, 2021, 7:40:04 PM8/22/21
to
On Sun, Aug 22, 2021 at 6:18 PM antlists <antl...@youngman.org.uk> wrote:
[...]
What you're missing, is that this code IS NOT USED.
The OP wants to delete a load of code from his system precisely to
ELIMINATE vulnerabilities. If the code ain't there, it don't need fixing.
Where do you get that impression from? The OP needs handling keyboard and mouse (as per his first email), and to do that in Linux these days, you basically need udev, because xf86-input-mouse and xf86-input-keyboard are going the way of the dodo.
Where does the "ELIMINATE vulnerabilities" come from? The OP is just complaining that to use keyboard and mouse, now he needs udev.
My point is that it's not his call; it's the call of the developers of the software that he decided to use.
Yes I take your point, but bloat is bloat, and bloat is a liability.
There is no bloat; the developers *need* to handle the dynamic hardware case *and* the static hardware case. With udev, they handle both; otherwise there would be two code routes: one for static and another for dynamic hardware.
THAT would be bloat; using udev solves all the cases and bloat is averted. Is exactly the contrary of what you are saying.
Regards.
--
--
ka...@aspodata.se
Aug 23, 2021, 12:10:04 PM8/23/21
to
Dr. Canek Peláez Valdés:
...
Regarding udev, it has never supported serial mice, so it doesn't help
me.
...
It is my call if I want to use that software or not.
> > Yes I take your point, but bloat is bloat, and bloat is a liability.
> >
>
> There is no bloat; the developers *need* to handle the dynamic hardware
> case *and* the static hardware case. With udev, they handle both; otherwise
> there would be two code routes: one for static and another for dynamic
> hardware.
...
As I wrote before, udev does not handle serial mice, so udev does not
solve anything for me nor does it help me in any way to run my systems.
Udev is just something pushed on me for no gain except possible to
satisfy some dependancy touted to be beneficial. So in this very
specific case it can be considered "bloat" if you wish to use that
kind of words.
My guess is that it is more useful on laptop than on a desktop box
or an industrial computer.
///
As a side note, from what I understand, udev today is mostly about
usb-devices because that is where the dynamic hardware comes from
today (at least when we are not talking about hotplugging cpus,
memory cards, io-cards and such (but that is more of a enterprise
problem than a small system problem.
Serial ports are darn easy to implement in hardware and
softwere.
E.g. if I have a program connecting to a device using a serial
and it is disconnected, I can just reconnect it and nothing
special happens, noting to be done in software except logging.
The same device via usb, the dis-/reconnect will close the
port and make it vanish forcing med to find out find out where the
new /dev file is and reopen and reinitialize it.
In hardware, mcu's without usb are cheap and their serial port
are simpe to program and the serial port "stack" is vanishingly small.
Just look at the tty_* files in
http://aspodata.se/git/openhw/libarm/
http://aspodata.se/git/openhw/libarm/stm32/
For usb support, I need an usb stack (which is larger), e.g.
https://github.com/libopencm3/libopencm3/tree/master/lib/usb
I need to understand the usb protocol and all thoose structs to fill
in, and in the end I get a system that is harder to program on the
host side for no gain other than that +5V is provided by usb.
Regards,
/Karl Hammar
...
> Where do you get that impression from? The OP needs handling keyboard and
> mouse (as per his first email), and to do that in Linux these days, you
> basically need udev, because xf86-input-mouse and xf86-input-keyboard are
> going the way of the dodo.
It is inconvenient that thoose two goes away.
> mouse (as per his first email), and to do that in Linux these days, you
> basically need udev, because xf86-input-mouse and xf86-input-keyboard are
> going the way of the dodo.
Regarding udev, it has never supported serial mice, so it doesn't help
me.
...
> My point is that it's not his call; it's the call of the developers of the
> software that he decided to use.
Poeple write whatever software they want to or are paid to do.
> software that he decided to use.
It is my call if I want to use that software or not.
> > Yes I take your point, but bloat is bloat, and bloat is a liability.
> >
>
> There is no bloat; the developers *need* to handle the dynamic hardware
> case *and* the static hardware case. With udev, they handle both; otherwise
> there would be two code routes: one for static and another for dynamic
> hardware.
As I wrote before, udev does not handle serial mice, so udev does not
solve anything for me nor does it help me in any way to run my systems.
Udev is just something pushed on me for no gain except possible to
satisfy some dependancy touted to be beneficial. So in this very
specific case it can be considered "bloat" if you wish to use that
kind of words.
My guess is that it is more useful on laptop than on a desktop box
or an industrial computer.
///
As a side note, from what I understand, udev today is mostly about
usb-devices because that is where the dynamic hardware comes from
today (at least when we are not talking about hotplugging cpus,
memory cards, io-cards and such (but that is more of a enterprise
problem than a small system problem.
Serial ports are darn easy to implement in hardware and
softwere.
E.g. if I have a program connecting to a device using a serial
and it is disconnected, I can just reconnect it and nothing
special happens, noting to be done in software except logging.
The same device via usb, the dis-/reconnect will close the
port and make it vanish forcing med to find out find out where the
new /dev file is and reopen and reinitialize it.
In hardware, mcu's without usb are cheap and their serial port
are simpe to program and the serial port "stack" is vanishingly small.
Just look at the tty_* files in
http://aspodata.se/git/openhw/libarm/
http://aspodata.se/git/openhw/libarm/stm32/
For usb support, I need an usb stack (which is larger), e.g.
https://github.com/libopencm3/libopencm3/tree/master/lib/usb
I need to understand the usb protocol and all thoose structs to fill
in, and in the end I get a system that is harder to program on the
host side for no gain other than that +5V is provided by usb.
Regards,
/Karl Hammar
Vitor Hugo Nunes dos Santos
Aug 23, 2021, 12:20:03 PM8/23/21
to
ka...@aspodata.se
Aug 23, 2021, 1:10:03 PM8/23/21
to
Karl Hammar:
https://github.com/idunham/libsysdev
And what Anna <cy...@sysrq.in> gratiosly provided:
https://github.com/illiliti/libudev-zero
...
https://gitlab.freedesktop.org/mesa/drm/-/blob/main/xf86drm.c
The changes nessesary for a non-udev solution is smallish,
and it doesn't have to resort to polling as in the udev case.
A gui's need for pop-up windows when new devices are connected
could just as well be handled separate to the system thing of
/dev nodes, permissions and such. You don't need a daemon for
that, it just that the udev people just merged the use cases.
...
> As a side note,
...
As an actual case, this is a prototype for a three way mouse
to be used on ship bridges
http://aspodata.se/git/openhw/boards_arm_aspo/mouse/
Switching a knob, I can send mouse events to three different
computers, say for radar, maps, etc.
It uses microsoft serial mouse protocol.
This possible for low end mcu's since they contain multiple
serial interfaces.
If I had to use usb, well, not even a high end mcu's like
stm32f4 has more than two usb ports.
Regards,
/Karl Hammar
> Dr. Canek Peláez Valdés:
...
...
> > My point is that it's not his call; it's the call of the developers of the
> > software that he decided to use.
>
> Poeple write whatever software they want to or are paid to do.
> It is my call if I want to use that software or not.
For what some people want to work on, here is an alternative api:
> > software that he decided to use.
>
> Poeple write whatever software they want to or are paid to do.
> It is my call if I want to use that software or not.
https://github.com/idunham/libsysdev
And what Anna <cy...@sysrq.in> gratiosly provided:
https://github.com/illiliti/libudev-zero
...
> > There is no bloat; the developers *need* to handle the dynamic hardware
> > case *and* the static hardware case. With udev, they handle both; otherwise
> > there would be two code routes: one for static and another for dynamic
> > hardware.
As an example of that is:
> > case *and* the static hardware case. With udev, they handle both; otherwise
> > there would be two code routes: one for static and another for dynamic
> > hardware.
https://gitlab.freedesktop.org/mesa/drm/-/blob/main/xf86drm.c
The changes nessesary for a non-udev solution is smallish,
and it doesn't have to resort to polling as in the udev case.
A gui's need for pop-up windows when new devices are connected
could just as well be handled separate to the system thing of
/dev nodes, permissions and such. You don't need a daemon for
that, it just that the udev people just merged the use cases.
...
> As a side note,
...
As an actual case, this is a prototype for a three way mouse
to be used on ship bridges
http://aspodata.se/git/openhw/boards_arm_aspo/mouse/
Switching a knob, I can send mouse events to three different
computers, say for radar, maps, etc.
It uses microsoft serial mouse protocol.
This possible for low end mcu's since they contain multiple
serial interfaces.
If I had to use usb, well, not even a high end mcu's like
stm32f4 has more than two usb ports.
Regards,
/Karl Hammar
Canek Peláez Valdés
Aug 23, 2021, 4:00:04 PM8/23/21
to
On Mon, Aug 23, 2021 at 11:07 AM <ka...@aspodata.se> wrote:
[...]
It is inconvenient that thoose two goes away. Regarding udev, it has never supported serial mice, so it doesn't help me.
What are you talking about? Udev doesn't "support" any hardware; as the manual page states[1], it: "supplies the system software with device events, manages permissions of device nodes and may create additional symlinks in the /dev/ directory, or renames network interfaces".
If the kernel supports the hardware, udev will supply the corresponding event, so udev will generate the corresponding event for serial mice also (probably close to boot time).
[...]
Poeple write whatever software they want to or are paid to do. It is my call if I want to use that software or not.
Well, yeah; but if you want to use software X, and X depends on Y, then you either use software Y or don't use software X. The dependency chain can and will grow depending on several factors, and it's the situation here if I'm not mistaken: you want to keep using keyboard and mice, those depend on libinput, and libinput depends on udev.
There are alternatives, of course; some members have posted several working ones; but the fact is that either you accept the dependencies dictated by the software you want to use, or you need an alternative that *someone* has to write/debug/maintain, etc. You said: "[u]dev should be an optional daemon, utilized when the local administrator decides to do so," and that is simply not true: if a software you use decides to depend on udev, then you either use udev, or need to change to a different software.
As I wrote before, udev does not handle serial mice, so udev does not solve anything for me nor does it help me in any way to run my systems.
You are saying it wrong, you mean to say: "to handle serial mice, I don't need udev". And that is 100% completely true; you can keep a static /dev, don't use udev and create the device nodes by hand. But serial mice work great under udev also.
The thing is, the *GREAT* majority of users need support for dynamic hardware, so the developers of most of the software in Linux solve the general problem: dynamic hardware (which includes static hardware also). So they do that, and you complain about daemons that are needed for other people other than you.
But you didn't write the software that depends on udev; someone else (worrying about the general problem) did. So either you write your own version, or find someone else who does (again, check the alternatives).
Udev is just something pushed on me for no gain except possible to satisfy some dependancy touted to be beneficial.
For no gain *TO YOU*. You want software that someone else wrote to cater to *ONLY* your needs. That's not how it works; *MOST* developers will cater to the needs of the *MAJORITY* of users, and that includes the dynamic hardware scenario (which has been the case for all of the XXI century, by the way).
So in this very specific case it can be considered "bloat" if you wish to use that kind of words.
My guess is that it is more useful on laptop than on a desktop box or an industrial computer.
Of course not; desktop and servers ("industrial computers") need dynamic hardware (hot swappable storage, anyone?, disconnect the webcam after the Zoom meeting?) Just because you in particular don't find it useful doesn't mean it isn't: the truth is, dynamic hardware users surpass static hardware users, and it has been the case for several decades now.
As a side note, from what I understand, udev today is mostly about usb-devices because that is where the dynamic hardware comes from today (at least when we are not talking about hotplugging cpus, memory cards, io-cards and such (but that is more of a enterprise problem than a small system problem.
It's not only USB; it's Bluetooth, Thunderbolt, eSATA and eSATAp, etc. The computing world is dominated by dynamic hardware; it has been so for at least the last two decades.
Serial ports are darn easy to implement in hardware and softwere.
Yes: but the software that *uses* mice doesn't care *ONLY* about serial port mice. They care about USB mice (which is the majority) and Bluetooth mice (which has the second place). Right now, serial mice have to be a distant third place, if at all.
So the developers of software that deals with mice don't need to worry *ONLY* about your case; they need to worry about the general case. Which includes USB and Bluetooth (and whatever they invent in the future).
E.g. if I have a program connecting to a device using a serial
and it is disconnected, I can just reconnect it and nothing
special happens, noting to be done in software except logging.
The same device via usb, the dis-/reconnect will close the
port and make it vanish forcing med to find out find out where the
new /dev file is and reopen and reinitialize it.
That is what udev+libinput solves, *exactly*. You answered yourself why it is needed *IN GENERAL* (not in your particular case).
What you say about complexity etc., is true; but most developers care about servicing the *majority* of users (in this case, USB and Bluetooth users included), so if you want to use their software, that means accepting udev. If you don't like it, you need to stop using their software and either write your own or find someone else who does it (again, check the alternatives).
In any case, complaining is useless: most sane developers always want to cover the majority of users. That's why udev is mandatory in most major and medium distros; in Gentoo it is used by default (BTW, they are preparing the deprecation of eudev in Gentoo[2]).
Regards.
ka...@aspodata.se
Aug 23, 2021, 6:40:03 PM8/23/21
to
Dr. Canek Peláez Valdés:
Even if I pop in a usb-disk, I just mount it.
Udev do not in the slightest solve any of my needs.
So why are you telling me that I must have it, yes, software
dependancies are a problem. I'm interested in answers that tells me how
to solve that without calling in extra software and deamons.
> If the kernel supports the hardware, udev will supply the corresponding
> event, so udev will generate the corresponding event for serial mice also
> (probably close to boot time).
You can try gpm to do that.
Udev do not do any way of serial mouce detection, never has.
> > Poeple write whatever software they want to or are paid to do. It is my
> > call if I want to use that software or not.
> Well, yeah; but if you want to use software X, and X depends on Y, then you
> either use software Y or don't use software X. The dependency chain can and
> will grow depending on several factors, and it's the situation here if I'm
> not mistaken: you want to keep using keyboard and mice, those depend on
> libinput, and libinput depends on udev.
I'm not a passive consumer in this as you seem to believe.
If I decide I will resurrect thoose x11 drivers, I will do so.
...
> > As I wrote before, udev does not handle serial mice, so udev does not
> > solve anything for me nor does it help me in any way to run my systems.
> You are saying it wrong, you mean to say: "to handle serial mice, I don't
> need udev". And that is 100% completely true; you can keep a static /dev,
> don't use udev and create the device nodes by hand. But serial mice
> work great under udev also.
Yea, it does, simply because udev doesn't touch any serial mouse,
you have to fill in your own xorg.conf section for that or use gpm
in a console. Udev just cares about the serial port, not what is
attached to that port
> It's not only USB; it's Bluetooth, Thunderbolt, eSATA and eSATAp, etc. The
> computing world is dominated by dynamic hardware; it has been so for at
> least the last two decades.
Bluetooth adapters mostly comes in as a usb device, thought there might
be thoose with an i2c connection for the embedded market.
I don't know about thunderbolt.
esata as well as sata just works well without udev.
And I do not need a deamon to handle that.
> > Serial ports are darn easy to implement in hardware and softwere.
..
What I'm looking for is alternatives.
> So the developers of software that deals with mice don't need to worry
> *ONLY* about your case; they need to worry about the general case. Which
> includes USB and Bluetooth (and whatever they invent in the future).
So, udev isn't for me, what do you complain about.
I don't say to others to not use udev, I don't care about that.
I ask, how can I make my case work without udev, because honsestly,
it doesn't bring me shit and I'm not interesed in using software that
doesn't do anything for me. The problem of device nodes and permission
is already solved, I don't need pop-ups, I don't want automounting.
Serial ports have been working for the last 70 years or more.
So stop this, I never asked about udev or how to make that work.
You are answering the wrong question.
Regards,
/Karl Hammar
> > Regarding udev, it has never
> > supported serial mice, so it doesn't help me.
> What are you talking about? Udev doesn't "support" any hardware; as the
> manual page states[1], it: "supplies the system software with device
> events, manages permissions of device nodes and may create additional
> symlinks in the /dev/ directory, or renames network interfaces".
Why would I need such a thing, I don't need any changes to /dev.
> > supported serial mice, so it doesn't help me.
> What are you talking about? Udev doesn't "support" any hardware; as the
> manual page states[1], it: "supplies the system software with device
> events, manages permissions of device nodes and may create additional
> symlinks in the /dev/ directory, or renames network interfaces".
Even if I pop in a usb-disk, I just mount it.
Udev do not in the slightest solve any of my needs.
So why are you telling me that I must have it, yes, software
dependancies are a problem. I'm interested in answers that tells me how
to solve that without calling in extra software and deamons.
> If the kernel supports the hardware, udev will supply the corresponding
> event, so udev will generate the corresponding event for serial mice also
> (probably close to boot time).
Udev do not do any way of serial mouce detection, never has.
> > Poeple write whatever software they want to or are paid to do. It is my
> > call if I want to use that software or not.
> Well, yeah; but if you want to use software X, and X depends on Y, then you
> either use software Y or don't use software X. The dependency chain can and
> will grow depending on several factors, and it's the situation here if I'm
> not mistaken: you want to keep using keyboard and mice, those depend on
> libinput, and libinput depends on udev.
If I decide I will resurrect thoose x11 drivers, I will do so.
...
> > As I wrote before, udev does not handle serial mice, so udev does not
> > solve anything for me nor does it help me in any way to run my systems.
> You are saying it wrong, you mean to say: "to handle serial mice, I don't
> need udev". And that is 100% completely true; you can keep a static /dev,
> don't use udev and create the device nodes by hand. But serial mice
> work great under udev also.
you have to fill in your own xorg.conf section for that or use gpm
in a console. Udev just cares about the serial port, not what is
attached to that port
> It's not only USB; it's Bluetooth, Thunderbolt, eSATA and eSATAp, etc. The
> computing world is dominated by dynamic hardware; it has been so for at
> least the last two decades.
be thoose with an i2c connection for the embedded market.
I don't know about thunderbolt.
esata as well as sata just works well without udev.
And I do not need a deamon to handle that.
> > Serial ports are darn easy to implement in hardware and softwere.
> Yes: but the software that *uses* mice doesn't care *ONLY* about serial
> port mice. They care about USB mice (which is the majority) and Bluetooth
> mice (which has the second place). Right now, serial mice have to be a
> distant third place, if at all.
Well, "if at all", so you agree with me that udev isn't for me.
> port mice. They care about USB mice (which is the majority) and Bluetooth
> mice (which has the second place). Right now, serial mice have to be a
> distant third place, if at all.
What I'm looking for is alternatives.
> So the developers of software that deals with mice don't need to worry
> *ONLY* about your case; they need to worry about the general case. Which
> includes USB and Bluetooth (and whatever they invent in the future).
I don't say to others to not use udev, I don't care about that.
I ask, how can I make my case work without udev, because honsestly,
it doesn't bring me shit and I'm not interesed in using software that
doesn't do anything for me. The problem of device nodes and permission
is already solved, I don't need pop-ups, I don't want automounting.
Serial ports have been working for the last 70 years or more.
So stop this, I never asked about udev or how to make that work.
You are answering the wrong question.
Regards,
/Karl Hammar
0 new messages