From: karl@aspodata.se
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] X11 without udev/eudev
Date: Tue, 24 Aug 2021 00:36:12 +0200 (CEST) [thread overview]
Message-ID: <20210823223612.6F9388517F54@turkos.aspodata.se> (raw)
In-Reply-To: <CADPrc82DX2oWYj-SHLPo8vR7AhiaoLheQ6k-NyFP=R7rd24smw@mail.gmail.com>
Dr. Canek Peláez Valdés:
> On Mon, Aug 23, 2021 at 11:07 AM <karl@aspodata.se> wrote:
...
> > 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.
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.
..
> 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.
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
next prev parent reply other threads:[~2021-08-23 22:36 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-21 20:17 [gentoo-user] X11 without udev/eudev karl
2021-08-21 21:02 ` antlists
2021-08-21 22:34 ` karl
2021-08-21 21:05 ` Anna “CyberTailor”
2021-08-22 20:31 ` karl
2021-08-22 21:59 ` Canek Peláez Valdés
2021-08-22 23:18 ` antlists
2021-08-22 23:30 ` Rich Freeman
2021-08-22 23:37 ` Canek Peláez Valdés
2021-08-23 16:07 ` karl
2021-08-23 17:01 ` karl
2021-08-23 19:51 ` Canek Peláez Valdés
2021-08-23 22:36 ` karl [this message]
2021-08-23 16:14 ` Vitor Hugo Nunes dos Santos
2021-08-21 21:51 ` Vitor Hugo Nunes dos Santos
2021-08-21 22:34 ` karl
2021-08-21 22:45 ` Neil Bothwick
2021-08-22 11:01 ` Mart Raudsepp
2021-08-22 20:31 ` karl
2021-08-22 20:31 ` karl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210823223612.6F9388517F54@turkos.aspodata.se \
--to=karl@aspodata.se \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox