Re: [systemd-devel] Udev rules for hardware speech synths

[Barry]

On 5 Mar 2026, at 19:33, Andrei Borzenkov  wrote:Typically what is in the initramfs is the support for the detected hardware on the system.On 5 Mar 2026, at 16:33, John G. Heim  wrote:So not all kernel modules are even included in the intramfs? I know that many of them are not loaded but you[re saying they aren't even in there unless you specify it?This is because adding all modules would create a huge initramfs.Typically what is in the initramfs is the support for the detected hardware on the system.No. What is in initramfs is what is needed to mount root filesystem. This is what initramfs is for.To mount a file system needs GPU firmware, GPU driver and a network stack if you have luks encrypted disk unlocked with clevis potentially.Why not a speach driver?Barry

Re: [systemd-devel] Udev rules for hardware speech synths

[Andrei Borzenkov]

05.03.2026 21:50, Barry Scott wrote:




On 5 Mar 2026, at 16:33, John G. Heim  wrote:

So not all kernel modules are even included in the intramfs? I know that many 
of them are not loaded but you[re saying they aren't even in there unless you 
specify it?


This is because adding all modules would create a huge initramfs.

Typically what is in the initramfs is the support for the detected hardware on 
the system.


No. What is in initramfs is what is needed to mount root filesystem. 
This is what initramfs is for.



You are expected to customise the tool that builds initramfs, in Fedora that is 
dracut.
It is possible to create a bugger initramfs that includes a wide range of 
modules,
but far from all of them.

Barry

Re: [systemd-devel] Udev rules for hardware speech synths

[John G. Heim]

It seems to me that it may be better to build a modern software speech
generator into the initramfs and use a simple hardware dongle to
activate it if necessary.



But what if the server doesn't have a sound card? Maybe you could say 
that if you plug in a USB headset it starts speech? After all, there 
would be no  reason to  plug in a USB headset other than to get 
speech. That's how some ATMs work. They detect that you have plugged a 
headset into the jack and start speech.

Re: [systemd-devel] Udev rules for hardware speech synths

[Barry Scott]

> On 5 Mar 2026, at 16:33, John G. Heim  wrote:
> 
> So not all kernel modules are even included in the intramfs? I know that many 
> of them are not loaded but you[re saying they aren't even in there unless you 
> specify it?

This is because adding all modules would create a huge initramfs.

Typically what is in the initramfs is the support for the detected hardware on 
the system.
You are expected to customise the tool that builds initramfs, in Fedora that is 
dracut.
It is possible to create a bugger initramfs that includes a wide range of 
modules,
but far from all of them.

Barry

Re: [systemd-devel] Udev rules for hardware speech synths

[Dave Howorth]

On Wed, 25 Feb 2026 10:25:05 -0600
"John G. Heim"  wrote:
> I would like to make it possible for a blind Linux user to plug a 
> hardware speech synth into a USB port and get speech w/o having to
> type anything.
> 
> I think you can understand the motivation for this -- it is hard to
> type in a command to start speech if you don't have speech. It's like
> having to type in a command to turn on your monitor when your monitor
> isn't working.
> 
> And  I know it's possible because I've done it by adding my own rules
> to /etc/udev/rules.d/.
> 
> I've collected ID info for 3 hardware synths and  I can get more.
> What I need to know is what I have to do to get these rules into
> Linux proper.
> 
> Of course, I am willing to do all the work. I just need direction.

Hi John, everybody else ...

I'm posting late to this thread but am replying to the initial post to
supply some additional information. I'm not involved in the effort in
any way.

The speakup package has its own web page at
http://www.linux-speakup.org/speakup.html

The page may or may not be up to date; I don't know. But it includes a
list of synthesizers, some of which are hardware and some are software.
It seems that AI is changing the field a lot, with more emphasis on
software now.

I think it would be useful if John shared details of the synths he has
identified, so people can help him decide on the best way to approach
identification. It seems clear, based on his requirements and other
people's knowledge, that recognising the hardware either at boot (grub)
or in the initramfs will be necessary.

It seems to me that it may be better to build a modern software speech
generator into the initramfs and use a simple hardware dongle to
activate it if necessary.

Re: [systemd-devel] Udev rules for hardware speech synths

[John G. Heim]

Again, I was unaware of the fact that there are 2 different mechanisms 
for a USB device to be recognized.   I thought the kernel used udev rules.


So not all kernel modules are even included in the intramfs? I know that 
many of them are not loaded but you[re saying they aren't even in there 
unless you specify it?


This does seem like a significant problem even in the best case 
scenario. Obviously there is some process by which certain modules are 
always included. But we'll never get the speakup modules added to that list.


Hmm, even as I write, I'm  thinking maybe one synth could be supported. 
You  have to  have a particular synth (or one  that emulates it) to  get 
speech. That's a reasonable demand to make of a blind systems engineer.




On 3/5/26 3:50 AM, Andrei Borzenkov wrote:

On Wed, Mar 4, 2026 at 10:49 PM John G. Heim  wrote:



I wonder if loading in the initramfs is what is required here?

Is that what you have been doing?

Barry




Yes, that's mostly what I've been doing for the past couple of decades.
But I've also compiled the modules into the kernel from time to time.

Of course, the problem with both of those approaches is that you have to
set it up ahead of time -- which is not practical in a corporate or
departmental-level environment. You can't make sure every machine has
speakup configured in the initramfs  unless you do the installation for
every machine.



And how exactly defining udev rules is going to solve it? If necessary
kernel drivers are built as modules they need to be loaded from the
user space before they can be used. Period. If you do not include
these modules in the initramfs, the speech synthesizing will not be
available until after switching to the real root.

The only way to make sure this functionality is available as soon as
the kernel is loaded is to make these drivers built-in. Otherwise you
need to accept that the functionality will only be available later and
the only question is - how late.

Re: [systemd-devel] Udev rules for hardware speech synths

[John G. Heim]

It's  not reasonable/realistic to expect the kernel  to recognize all 
synths. Most of the synths were originally manufactured before there 
even was such a thing as USB. Some of them added USB connections after. 
Some newer ones were manufactured with USB. The last 2 categories are 
the ones I am talking about. A blind systems admin would have  to have  
one of  the synths that the kernel can identify. The  code to  talk to 
these synths is in drivers/accessibility/speakup/spk_ttyio.c.


I  have manufacturer/product ID numbers for 3 hardware synths. I am sure 
I can get more by asking on lists for blind sys admins. I can  write 
UDEV  rules for those 3 synths and put them into a Debian package or 
(better yet) get them added to the speakup_utils package. That would be  
an improvement. But it would be much better if a blind systems admin 
didn't have to customize a machine in order to work with it.


I'm sorry, I thought we were already real close to that. I thought this 
would be easy since it's just a matter of recognizing the synth by USB 
manufacturer/product ID and loading the appropriate kernel module.





On 3/5/26 4:13 AM, Andrei Borzenkov wrote:

On Wed, Mar 4, 2026 at 8:56 PM Adrian Vovk  wrote:

Hello,

I'm trying to understand what you need, because I'm seeing conflicting 
information.

On one hand, you explain that the point of speakup is to have speech working 
before userspace is even available. In this case, touching udev or systemd or 
anything like that is moot because these are all userspace components. What you 
actually need to do is solve this in the kernel.

On the other hand, you're saying that udev rules work well enough, and here 
you're suggesting that the equivalent of running `modprobe` is too. This, of 
course, is a userspace action and it will not help you with getting speakup 
working before userspace.

If all that needs to happen is that modprobe command, then yeah udev rules will 
do the trick and a contribution to systemd will likely be welcome. Depending on 
what your udev rules do, maybe you can also just get away with adding modalias 
information to the speakup kernel modules, and then you don't even need to 
touch udev because it will automatically match on modalias and load the right 
drivers for you.


Looking at the drivers/accessibility/speakup - the synthesizer drivers
are not USB, they appear to work via serial port, in the case of USB
hardware you point them to the emulated serial port. It would be
interesting to see an example of such a device and its properties.

Re: [systemd-devel] Udev rules for hardware speech synths

[John G. Heim]

Oh yes, it never even occurred to me to try to identify a synth 
connected via a serial port. I am talking about synths that have a USB 
connection and  can therefore be identified by manufacturer ID and 
product ID.



On 3/5/26 6:07 AM, Simon McVittie wrote:

On Wed, 04 Mar 2026 at 13:34:26 -0600, John G. Heim wrote:

I thought the kernel used udev rules to load modules for the hardware it finds
connected  to the system.

In an ideal world, the kernel mostly uses its own knowledge of the
mapping between devices and drivers to load modules for the hardware
that it finds. For example, video cards have a PCI ID, and video
drivers have a table of PCI IDs that the driver supports, so the
kernel can load an appropriate driver module. Similarly, USB devices
can be self-identifying. If hardware speech synths are similarly
self-identifying, then the kernel could be taught to recognise them
automatically, but if they are not, then that won't be possible.

 From what you've said earlier in this thread, it seems that hardware
speech synths are serial-port-based devices. This is a potential pitfall
in what you're trying to do. For a device attached to a physical RS232
serial port, automatic identification isn't going to be possible because
serial devices are not self-identifying: there is no single consistent
way to retrieve a vendor/product ID from an unknown serial device,
because the design of serial ports is older and simpler than the "plug
and play" concept. But, for a device that is permanently attached to a
USB-to-serial bridge chip, it might be possible to identify a hardware
speech synth automatically based on the USB vendor and product IDs that
the USB-to-serial bridge reports - it depends whether those vendor/product
IDs are unique to the attached device or not.

If the manufacturer of the hardware speech synth has kept the generic
USB vendor/product IDs of the USB-to-serial bridge chip, for example
067B:2303 for the widely-used PL2303, then you're out of luck: for
a device that just reports "I am a USB-to-serial bridge" there is no
reliable way to tell what serial device is attached to the other side,
and whether it's a hardware speech synth, a modem, a smart-card reader,
a 1970s teletype, or whatever. This is a common problem for devices
manufactured in low volumes and intended to be used in specialized
scenarios by a user who knows what they're doing and is willing to
apply additional configuration. If the kernel or udev automatically
treated these devices as hardware speech synths, then that would break
the ability to use other devices that happen to have incorporated the
same USB-to-serial bridge but are using it for a different purpose.

However, if the USB-to-serial bridge is permanently connected to the
speech synth, and the manufacturer has overridden the USB-to-serial bridge
chip's vendor/product IDs so that it reports itself as "I am a hardware
speech synth" instead of "I am a USB-to-serial bridge", then it should
in principle be possible to auto-detect it. For example, the SoloKey 2
authentication dongle is a device that integrates a USB-to-serial bridge,
but because it has its own dedicated USB vendor/product IDs (vendor 1209,
product BEEE), the kernel or a udev rule can positively identify it as a
SoloKey, and not some other serial device like a hardware speech synth
or a modem. This is the good way to implement USB devices that use a
serial-port-based protocol internally, and if hardware speech synth
manufacturers have done similarly, then their products would be safe
to auto-detect.

I don't know which of those two categories your specific hardware speech
synth devices fall into. Perhaps some of them will be safe to auto-detect
but others will not.

For devices that will be used during early boot on a modular kernel,
another thing that needs to happen is to identify categories of module
that are going to be required during early boot (for example video
cards or hardware speech synths), and teach the tool that creates the
initramfs (dracut or similar) to include those kernel modules in the
initramfs. Otherwise, there's no way those modules are going to get loaded
until the handover from initramfs to main system, however good the kernel
is at detecting devices and however many udev rules you might add.

 smcv

Re: [systemd-devel] Udev rules for hardware speech synths

[Simon McVittie]

On Wed, 04 Mar 2026 at 13:34:26 -0600, John G. Heim wrote:
> I thought the kernel used udev rules to load modules for the hardware it finds
> connected  to the system.

In an ideal world, the kernel mostly uses its own knowledge of the
mapping between devices and drivers to load modules for the hardware
that it finds. For example, video cards have a PCI ID, and video
drivers have a table of PCI IDs that the driver supports, so the
kernel can load an appropriate driver module. Similarly, USB devices
can be self-identifying. If hardware speech synths are similarly
self-identifying, then the kernel could be taught to recognise them
automatically, but if they are not, then that won't be possible.

>From what you've said earlier in this thread, it seems that hardware
speech synths are serial-port-based devices. This is a potential pitfall
in what you're trying to do. For a device attached to a physical RS232
serial port, automatic identification isn't going to be possible because
serial devices are not self-identifying: there is no single consistent
way to retrieve a vendor/product ID from an unknown serial device,
because the design of serial ports is older and simpler than the "plug
and play" concept. But, for a device that is permanently attached to a
USB-to-serial bridge chip, it might be possible to identify a hardware
speech synth automatically based on the USB vendor and product IDs that
the USB-to-serial bridge reports - it depends whether those vendor/product
IDs are unique to the attached device or not.

If the manufacturer of the hardware speech synth has kept the generic
USB vendor/product IDs of the USB-to-serial bridge chip, for example
067B:2303 for the widely-used PL2303, then you're out of luck: for
a device that just reports "I am a USB-to-serial bridge" there is no
reliable way to tell what serial device is attached to the other side,
and whether it's a hardware speech synth, a modem, a smart-card reader,
a 1970s teletype, or whatever. This is a common problem for devices
manufactured in low volumes and intended to be used in specialized
scenarios by a user who knows what they're doing and is willing to
apply additional configuration. If the kernel or udev automatically
treated these devices as hardware speech synths, then that would break
the ability to use other devices that happen to have incorporated the
same USB-to-serial bridge but are using it for a different purpose.

However, if the USB-to-serial bridge is permanently connected to the
speech synth, and the manufacturer has overridden the USB-to-serial bridge
chip's vendor/product IDs so that it reports itself as "I am a hardware
speech synth" instead of "I am a USB-to-serial bridge", then it should
in principle be possible to auto-detect it. For example, the SoloKey 2
authentication dongle is a device that integrates a USB-to-serial bridge,
but because it has its own dedicated USB vendor/product IDs (vendor 1209,
product BEEE), the kernel or a udev rule can positively identify it as a
SoloKey, and not some other serial device like a hardware speech synth
or a modem. This is the good way to implement USB devices that use a
serial-port-based protocol internally, and if hardware speech synth
manufacturers have done similarly, then their products would be safe
to auto-detect.

I don't know which of those two categories your specific hardware speech
synth devices fall into. Perhaps some of them will be safe to auto-detect
but others will not.

For devices that will be used during early boot on a modular kernel,
another thing that needs to happen is to identify categories of module
that are going to be required during early boot (for example video
cards or hardware speech synths), and teach the tool that creates the
initramfs (dracut or similar) to include those kernel modules in the
initramfs. Otherwise, there's no way those modules are going to get loaded
until the handover from initramfs to main system, however good the kernel
is at detecting devices and however many udev rules you might add.

smcv

Re: [systemd-devel] Udev rules for hardware speech synths

[Andrei Borzenkov]

On Wed, Mar 4, 2026 at 8:56 PM Adrian Vovk  wrote:
>
> Hello,
>
> I'm trying to understand what you need, because I'm seeing conflicting 
> information.
>
> On one hand, you explain that the point of speakup is to have speech working 
> before userspace is even available. In this case, touching udev or systemd or 
> anything like that is moot because these are all userspace components. What 
> you actually need to do is solve this in the kernel.
>
> On the other hand, you're saying that udev rules work well enough, and here 
> you're suggesting that the equivalent of running `modprobe` is too. This, of 
> course, is a userspace action and it will not help you with getting speakup 
> working before userspace.
>
> If all that needs to happen is that modprobe command, then yeah udev rules 
> will do the trick and a contribution to systemd will likely be welcome. 
> Depending on what your udev rules do, maybe you can also just get away with 
> adding modalias information to the speakup kernel modules, and then you don't 
> even need to touch udev because it will automatically match on modalias and 
> load the right drivers for you.
>

Looking at the drivers/accessibility/speakup - the synthesizer drivers
are not USB, they appear to work via serial port, in the case of USB
hardware you point them to the emulated serial port. It would be
interesting to see an example of such a device and its properties.

Re: [systemd-devel] Udev rules for hardware speech synths

[Andrei Borzenkov]

On Wed, Mar 4, 2026 at 10:49 PM John G. Heim  wrote:
>
>
> > I wonder if loading in the initramfs is what is required here?
> >
> > Is that what you have been doing?
> >
> > Barry
> >
> >
>
>
> Yes, that's mostly what I've been doing for the past couple of decades.
> But I've also compiled the modules into the kernel from time to time.
>
> Of course, the problem with both of those approaches is that you have to
> set it up ahead of time -- which is not practical in a corporate or
> departmental-level environment. You can't make sure every machine has
> speakup configured in the initramfs  unless you do the installation for
> every machine.
>
>

And how exactly defining udev rules is going to solve it? If necessary
kernel drivers are built as modules they need to be loaded from the
user space before they can be used. Period. If you do not include
these modules in the initramfs, the speech synthesizing will not be
available until after switching to the real root.

The only way to make sure this functionality is available as soon as
the kernel is loaded is to make these drivers built-in. Otherwise you
need to accept that the functionality will only be available later and
the only question is - how late.

Re: [systemd-devel] Udev rules for hardware speech synths

[John G. Heim]

You're absolutely right. I need to go back and do my homework. I thought 
this was way easier than it is. But I did seek out advice before coming 
here. I guess I didn't explain the problem thoroughly enough to the 
person who sent me here.


I thought the kernel used udev rules to load modules for the hardware it 
finds connected  to the system. And I do get at least some boot messages 
via my udev rules. Of course, I have no way of knowing how many I'm 
missing. I get speech before the login prompt at least which is hugely 
important. But I haven't had to try to rescue a machine since I started 
using udev to load speakup modules. Since I didn't know the difference, 
it didn't occur to me that that might not work.


Besides doing myy homework, I'm going to have to go back to the Speakup 
team to find out what they think. What I need to do is to understand 
better when we need speech based on different kinds of possible 
failures. I haven't seen a machine faill to boot bcause of an fsck 
failure for years. But maybe I can deliberately create one of those and 
see what happens. I know of 3 ways to get speech before the login 
prompt. #1 compile the speakup modules into the kernel #2 load the 
module via initramfs #3 write a udev rule. I know  the first way gives 
you an opportunity to enter the root password and run fsck. But I don't 
even know if the second way does.









On 3/4/26 11:55 AM, Adrian Vovk wrote:

Hello,

I'm trying to understand what you need, because I'm seeing conflicting 
information.


On one hand, you explain that the point of speakup is to have speech 
working before userspace is even available. In this case, touching 
udev or systemd or anything like that is moot because these are all 
userspace components. What you actually need to do is solve this in 
the kernel.


On the other hand, you're saying that udev rules work well enough, and 
here you're suggesting that the equivalent of running `modprobe` is 
too. This, of course, is a userspace action and it will not help you 
with getting speakup working before userspace.


If all that needs to happen is that modprobe command, then yeah udev 
rules will do the trick and a contribution to systemd will likely be 
welcome. Depending on what your udev rules do, maybe you can also just 
get away with adding modalias information to the speakup kernel 
modules, and then you don't even need to touch udev because it will 
automatically match on modalias and load the right drivers for you.


Hope that helps,
Adrian

On Fri, Feb 27, 2026 at 11:49 PM John G. Heim  wrote:


On 2/25/26 1:23 PM, Greg KH wrote:
> Yes, the kernel driver speakup is in the kernel source, but it's
useless
> without the userspace tools.  So the udev rules should be part
of that
> userspace package as that's required before anything would normally
> work, as it's only those userspace packages that do anything
with those
> kernel device nodes that speakup exports to userspace.
>


You don't need to install anything other than the Linux kernel
itself to
get speech with a hardware synth. The kernel modules talk directly to
the hardware synth. Typically, to start speech with a hardware synth,
you would type something like this:


modprobe speakup_ltlk dev=ttyACM0

Re: [systemd-devel] Udev rules for hardware speech synths

[John G. Heim]

I wonder if loading in the initramfs is what is required here?

Is that what you have been doing?

Barry





Yes, that's mostly what I've been doing for the past couple of decades. 
But I've also compiled the modules into the kernel from time to time.


Of course, the problem with both of those approaches is that you have to 
set it up ahead of time -- which is not practical in a corporate or 
departmental-level environment. You can't make sure every machine has 
speakup configured in the initramfs  unless you do the installation for 
every machine.

Re: [systemd-devel] Udev rules for hardware speech synths

[Barry Scott]

> On 4 Mar 2026, at 17:55, Adrian Vovk  wrote:
> 
> Hello,
> 
> I'm trying to understand what you need, because I'm seeing conflicting 
> information.
> 
> On one hand, you explain that the point of speakup is to have speech working 
> before userspace is even available. In this case, touching udev or systemd or 
> anything like that is moot because these are all userspace components. What 
> you actually need to do is solve this in the kernel.
> 
> On the other hand, you're saying that udev rules work well enough, and here 
> you're suggesting that the equivalent of running `modprobe` is too. This, of 
> course, is a userspace action and it will not help you with getting speakup 
> working before userspace.
> 
> If all that needs to happen is that modprobe command, then yeah udev rules 
> will do the trick and a contribution to systemd will likely be welcome. 
> Depending on what your udev rules do, maybe you can also just get away with 
> adding modalias information to the speakup kernel modules, and then you don't 
> even need to touch udev because it will automatically match on modalias and 
> load the right drivers for you.

John,

I wonder if loading in the initramfs is what is required here?

Is that what you have been doing?

Barry


> 
> Hope that helps,
> Adrian
> 
> On Fri, Feb 27, 2026 at 11:49 PM John G. Heim  > wrote:
>> 
>> On 2/25/26 1:23 PM, Greg KH wrote:
>> > Yes, the kernel driver speakup is in the kernel source, but it's useless
>> > without the userspace tools.  So the udev rules should be part of that
>> > userspace package as that's required before anything would normally
>> > work, as it's only those userspace packages that do anything with those
>> > kernel device nodes that speakup exports to userspace.
>> >
>> 
>> 
>> You don't need to install anything other than the Linux kernel itself to 
>> get speech with a hardware synth. The kernel modules talk directly to 
>> the hardware synth. Typically, to start speech with a hardware synth, 
>> you would type something like this:
>> 
>> 
>> modprobe speakup_ltlk dev=ttyACM0
>> 
>> 
>> 
>> 

Re: [systemd-devel] Udev rules for hardware speech synths

[Adrian Vovk]

Hello,

I'm trying to understand what you need, because I'm seeing conflicting
information.

On one hand, you explain that the point of speakup is to have speech
working before userspace is even available. In this case, touching udev or
systemd or anything like that is moot because these are all userspace
components. What you actually need to do is solve this in the kernel.

On the other hand, you're saying that udev rules work well enough, and here
you're suggesting that the equivalent of running `modprobe` is too. This,
of course, is a userspace action and it will not help you with getting
speakup working before userspace.

If all that needs to happen is that modprobe command, then yeah udev rules
will do the trick and a contribution to systemd will likely be welcome.
Depending on what your udev rules do, maybe you can also just get away with
adding modalias information to the speakup kernel modules, and then you
don't even need to touch udev because it will automatically match on
modalias and load the right drivers for you.

Hope that helps,
Adrian

On Fri, Feb 27, 2026 at 11:49 PM John G. Heim  wrote:

>
> On 2/25/26 1:23 PM, Greg KH wrote:
> > Yes, the kernel driver speakup is in the kernel source, but it's useless
> > without the userspace tools.  So the udev rules should be part of that
> > userspace package as that's required before anything would normally
> > work, as it's only those userspace packages that do anything with those
> > kernel device nodes that speakup exports to userspace.
> >
>
>
> You don't need to install anything other than the Linux kernel itself to
> get speech with a hardware synth. The kernel modules talk directly to
> the hardware synth. Typically, to start speech with a hardware synth,
> you would type something like this:
>
>
> modprobe speakup_ltlk dev=ttyACM0
>
>
>
>
>

Re: [systemd-devel] Udev rules for hardware speech synths

[John G. Heim]

But, from what I have seen, most of these devices just show up as a
"generic USB serial device" and so you need the policy of how to
determine that it is a speakup device, and that happens in userspace,
and should be part of the speakup utils package.




Well, they can be  identified by their manufacturer and product id. If 
you plug in a LiteTalk hardware speech synthesizer you are going to want 
to load the speakup_ltlk module one way or another, even if you have to 
type in the modprobe command yourself. I am just saying it would be 
better if it was automatic because it is very difficult to type in a 
command without speech. That's like having to type in a command to turn 
your monitor on. How are you going to log in and type in a command to 
start the screen if the screen isn't working?



If it's based purely on USB IDs, then systemd already has precedent in 
hwdb.d/70-{lights,maker-tools,etc,etc}.hwdb for recognizing specific 
products by ID. I think it might be reasonable to have automatic 
module loading... although I wonder how speakup handles *un*plugging.




I doubt that it handles it at all.

Re: [systemd-devel] Udev rules for hardware speech synths

[Mantas Mikulėnas]

On 26/02/2026 03.40, Greg KH wrote:

On Wed, Feb 25, 2026 at 06:51:34PM -0600, John G. Heim wrote:

Great, but that's not udev's job, that's the kernel's job.  Work on
adding automatic hardware support to the respective drivers as userspace
isn't involved here as you describe.


Huh... I thought it was the udev system that recognized USB hardware based
on it's ID strings and loaded the appropriate kernel modules. I'm
misinformed then?  I mean, clearly you *can* do that in udev, right? I've
already written udev rules to do it.

I also do not understand your reference to user space.  I am about as sure
as I can be that user space is not involved in what I am trying to do.

Yes, udev does load kernel modules based on the USB device ids that the
kernel exports.  If you know of a way to properly describe speakup
devices, then the kernel should be exporting that information so that
udev can load speakup with that information.

But, from what I have seen, most of these devices just show up as a
"generic USB serial device" and so you need the policy of how to
determine that it is a speakup device, and that happens in userspace,
and should be part of the speakup utils package.


If it's based purely on USB IDs, then systemd already has precedent in 
hwdb.d/70-{lights,maker-tools,etc,etc}.hwdb for recognizing specific 
products by ID. I think it might be reasonable to have automatic module 
loading... although I wonder how speakup handles *un*plugging.

Re: [systemd-devel] Udev rules for hardware speech synths

[Greg KH]

On Wed, Feb 25, 2026 at 06:51:34PM -0600, John G. Heim wrote:
> 
> > Great, but that's not udev's job, that's the kernel's job.  Work on
> > adding automatic hardware support to the respective drivers as userspace
> > isn't involved here as you describe.
> > 
> 
> Huh... I thought it was the udev system that recognized USB hardware based
> on it's ID strings and loaded the appropriate kernel modules. I'm
> misinformed then?  I mean, clearly you *can* do that in udev, right? I've
> already written udev rules to do it.
> 
> I also do not understand your reference to user space.  I am about as sure
> as I can be that user space is not involved in what I am trying to do.

Yes, udev does load kernel modules based on the USB device ids that the
kernel exports.  If you know of a way to properly describe speakup
devices, then the kernel should be exporting that information so that
udev can load speakup with that information.

But, from what I have seen, most of these devices just show up as a
"generic USB serial device" and so you need the policy of how to
determine that it is a speakup device, and that happens in userspace,
and should be part of the speakup utils package.

thanks,

greg k-h

Re: [systemd-devel] Udev rules for hardware speech synths

[John G. Heim]

Ah sorry. Lookas like I am asking in the wrong place. A person from the 
kernel development community directed me here. And it made sense to me 
since I already have these udev rules. Sorry to have wated your time.





On 2/25/26 7:00 PM, Adrian Vovk wrote:

udev is a userspace service

Best,
Adrian

On Wed, Feb 25, 2026, 19:51 John G. Heim  wrote:


> Great, but that's not udev's job, that's the kernel's job.  Work on
> adding automatic hardware support to the respective drivers as
userspace
> isn't involved here as you describe.
>

Huh... I thought it was the udev system that recognized USB hardware
based on it's ID strings and loaded the appropriate kernel
modules. I'm
misinformed then?  I mean, clearly you *can* do that in udev, right?
I've already written udev rules to do it.

I also do not understand your reference to user space.  I am about as
sure as I can be that user space is not involved in what I am
trying to do.

Re: [systemd-devel] Udev rules for hardware speech synths

[Adrian Vovk]

udev is a userspace service

Best,
Adrian

On Wed, Feb 25, 2026, 19:51 John G. Heim  wrote:

>
> > Great, but that's not udev's job, that's the kernel's job.  Work on
> > adding automatic hardware support to the respective drivers as userspace
> > isn't involved here as you describe.
> >
>
> Huh... I thought it was the udev system that recognized USB hardware
> based on it's ID strings and loaded the appropriate kernel modules. I'm
> misinformed then?  I mean, clearly you *can* do that in udev, right?
> I've already written udev rules to do it.
>
> I also do not understand your reference to user space.  I am about as
> sure as I can be that user space is not involved in what I am trying to do.
>
>
>
>

Re: [systemd-devel] Udev rules for hardware speech synths

[John G. Heim]

Great, but that's not udev's job, that's the kernel's job.  Work on
adding automatic hardware support to the respective drivers as userspace
isn't involved here as you describe.



Huh... I thought it was the udev system that recognized USB hardware 
based on it's ID strings and loaded the appropriate kernel modules. I'm 
misinformed then?  I mean, clearly you *can* do that in udev, right? 
I've already written udev rules to do it.


I also do not understand your reference to user space.  I am about as 
sure as I can be that user space is not involved in what I am trying to do.

Re: [systemd-devel] Udev rules for hardware speech synths

[Greg KH]

On Wed, Feb 25, 2026 at 04:25:39PM -0600, John G. Heim wrote:
> The whole point of Speakup is to get speech before user space is even
> available. These days, that's about it's only purpose. Software speech in
> the GUI is way nicer. But that requires user space.
> 
> This is why what I'm doing is so important. You can't get speech while the
> Windows kernel is loading. But you can get speech while the Linux kernel is
> loading. These days, with all important computing being done on Linux
> machines, it's especially important for blind systems engineers to have full
> access to the kernel boot messages.
> 
> If we can get the kernel to recognize hardware speech synths,  a blind
> systems engineer will be able to walk up to any Linux server, plug in his
> hardware synth, and listen to it boot.

Great, but that's not udev's job, that's the kernel's job.  Work on
adding automatic hardware support to the respective drivers as userspace
isn't involved here as you describe.

thanks,

greg k-h

Re: [systemd-devel] Udev rules for hardware speech synths

[John G. Heim]

The whole point of Speakup is to get speech before user space is even 
available. These days, that's about it's only purpose. Software speech 
in the GUI is way nicer. But that requires user space.


This is why what I'm doing is so important. You can't get speech while 
the Windows kernel is loading. But you can get speech while the Linux 
kernel is loading. These days, with all important computing being done 
on Linux machines, it's especially important for blind systems engineers 
to have full access to the kernel boot messages.


If we can get the kernel to recognize hardware speech synths,  a blind 
systems engineer will be able to walk up to any Linux server, plug in 
his hardware synth, and listen to it boot.



On 2/25/26 2:22 PM, Adrian Vovk wrote:
Just saw the other branch of this thread, where I learned that there's 
other userspace software required for these devices to work. Almost 
certainly, if there's external userspace software required to use this 
hardware, then the udev rules belong in that software package and you 
can disregard my message.


On the other hand, there may be the possibility that there are udev 
rules that may make sense across different software packages. For 
instance: maybe such hardware speech synths are usable not only by 
speakup, but also by speech-dispatcher and GUI screen reader 
infrastructure. In that case, it may make sense to split up the udev 
rules between a common set (rules that should apply no matter what the 
consumer of the hardware is) and an app-specific set (i.e. rules that 
only apply to speakup or rules that apply only to speech-dispatcher). 
The common set may then be upstreamed into systemd, and the 
app-specific set would go into the individual software packages.


Hope that helps,
Adrian

On Wed, Feb 25, 2026 at 2:32 PM Adrian Vovk  wrote:

Hi John,

A good starting point would be to open a pull request with the
rules you've written, upstreaming them into systemd (i.e. into the
/rules.d directory in systemd's source tree)

From there, you'll get review comments about how to change your
rules into an upstreamable shape

Best,
Adrian

On Wed, Feb 25, 2026 at 11:39 AM John G. Heim
 wrote:

I would like to make it possible for a blind Linux user to plug a
hardware speech synth into a USB port and get speech w/o
having to type
anything.

I think you can understand the motivation for this -- it is
hard to type
in a command to start speech if you don't have speech. It's
like having
to type in a command to turn on your monitor when your monitor
isn't
working.

And  I know it's possible because I've done it by adding my
own rules to
/etc/udev/rules.d/.

I've collected ID info for 3 hardware synths and  I can get
more. What I
need to know is what I have to do to get these rules into
Linux proper.

Of course, I am willing to do all the work. I just need direction.

Re: [systemd-devel] Udev rules for hardware speech synths

[John G. Heim]

On 2/25/26 1:23 PM, Greg KH wrote:

Yes, the kernel driver speakup is in the kernel source, but it's useless
without the userspace tools.  So the udev rules should be part of that
userspace package as that's required before anything would normally
work, as it's only those userspace packages that do anything with those
kernel device nodes that speakup exports to userspace.




You don't need to install anything other than the Linux kernel itself to 
get speech with a hardware synth. The kernel modules talk directly to 
the hardware synth. Typically, to start speech with a hardware synth, 
you would type something like this:



modprobe speakup_ltlk dev=ttyACM0

Re: [systemd-devel] Udev rules for hardware speech synths

[Adrian Vovk]

Just saw the other branch of this thread, where I learned that there's
other userspace software required for these devices to work. Almost
certainly, if there's external userspace software required to use this
hardware, then the udev rules belong in that software package and you can
disregard my message.

On the other hand, there may be the possibility that there are udev rules
that may make sense across different software packages. For instance: maybe
such hardware speech synths are usable not only by speakup, but also by
speech-dispatcher and GUI screen reader infrastructure. In that case, it
may make sense to split up the udev rules between a common set (rules that
should apply no matter what the consumer of the hardware is) and an
app-specific set (i.e. rules that only apply to speakup or rules that apply
only to speech-dispatcher). The common set may then be upstreamed into
systemd, and the app-specific set would go into the individual software
packages.

Hope that helps,
Adrian

On Wed, Feb 25, 2026 at 2:32 PM Adrian Vovk  wrote:

> Hi John,
>
> A good starting point would be to open a pull request with the rules
> you've written, upstreaming them into systemd (i.e. into the /rules.d
> directory in systemd's source tree)
>
> From there, you'll get review comments about how to change your rules into
> an upstreamable shape
>
> Best,
> Adrian
>
> On Wed, Feb 25, 2026 at 11:39 AM John G. Heim  wrote:
>
>> I would like to make it possible for a blind Linux user to plug a
>> hardware speech synth into a USB port and get speech w/o having to type
>> anything.
>>
>> I think you can understand the motivation for this -- it is hard to type
>> in a command to start speech if you don't have speech. It's like having
>> to type in a command to turn on your monitor when your monitor isn't
>> working.
>>
>> And  I know it's possible because I've done it by adding my own rules to
>> /etc/udev/rules.d/.
>>
>> I've collected ID info for 3 hardware synths and  I can get more. What I
>> need to know is what I have to do to get these rules into Linux proper.
>>
>> Of course, I am willing to do all the work. I just need direction.
>>
>>
>>
>>
>>

Re: [systemd-devel] Udev rules for hardware speech synths

[Adrian Vovk]

Hi John,

A good starting point would be to open a pull request with the rules you've
written, upstreaming them into systemd (i.e. into the /rules.d directory in
systemd's source tree)

>From there, you'll get review comments about how to change your rules into
an upstreamable shape

Best,
Adrian

On Wed, Feb 25, 2026 at 11:39 AM John G. Heim  wrote:

> I would like to make it possible for a blind Linux user to plug a
> hardware speech synth into a USB port and get speech w/o having to type
> anything.
>
> I think you can understand the motivation for this -- it is hard to type
> in a command to start speech if you don't have speech. It's like having
> to type in a command to turn on your monitor when your monitor isn't
> working.
>
> And  I know it's possible because I've done it by adding my own rules to
> /etc/udev/rules.d/.
>
> I've collected ID info for 3 hardware synths and  I can get more. What I
> need to know is what I have to do to get these rules into Linux proper.
>
> Of course, I am willing to do all the work. I just need direction.
>
>
>
>
>

Re: [systemd-devel] Udev rules for hardware speech synths

[Greg KH]

On Wed, Feb 25, 2026 at 12:36:32PM -0600, John G. Heim wrote:
> Oh, I probably should have said the speech software, speakup,  is in the 
> kernel. When you plug in a hardware synth, it has to load a kernel module.
> There is no package to add this to.
> 
> Well, it could be added to a speakup utilities package but that would kind
> of defeat the purpose. The goal would be that a blind user doesn't have to
> do  anything on the machine before plugging in his hardware synth.install  a

Yes, the kernel driver speakup is in the kernel source, but it's useless
without the userspace tools.  So the udev rules should be part of that
userspace package as that's required before anything would normally
work, as it's only those userspace packages that do anything with those
kernel device nodes that speakup exports to userspace.

thanks,

greg k-h

Re: [systemd-devel] Udev rules for hardware speech synths

[John G. Heim]

Oh, I probably should have said the speech software, speakup,  is in 
the  kernel. When you plug in a hardware synth, it has to load a kernel 
module. There is no package to add this to.


Well, it could be added to a speakup utilities package but that would 
kind of defeat the purpose. The goal would be that a blind user doesn't 
have to do  anything on the machine before plugging in his hardware 
synth.install  a





On 2/25/26 10:48 AM, Mantas Mikulėnas wrote:
Generally such udev rules should be part of the speech software 
they're starting. (Other packages already do this, e.g. I think 
pcsclite brings its own rules to start pcscd.)


Systemd can ship rules which e.g. apply device-specific metadata or 
give /dev read access (like the various ID_FOO=1 hwdb.d rules), but it 
can't really install rules which try to start external software that 
might or might not be installed.



On Wed, Feb 25, 2026, 18:39 John G. Heim  wrote:

I would like to make it possible for a blind Linux user to plug a
hardware speech synth into a USB port and get speech w/o having to
type
anything.

I think you can understand the motivation for this -- it is hard
to type
in a command to start speech if you don't have speech. It's like
having
to type in a command to turn on your monitor when your monitor isn't
working.

And  I know it's possible because I've done it by adding my own
rules to
/etc/udev/rules.d/.

I've collected ID info for 3 hardware synths and  I can get more.
What I
need to know is what I have to do to get these rules into Linux
proper.

Of course, I am willing to do all the work. I just need direction.

Re: [systemd-devel] Udev rules for hardware speech synths

[Mantas Mikulėnas]

Generally such udev rules should be part of the speech software they're
starting. (Other packages already do this, e.g. I think pcsclite brings its
own rules to start pcscd.)

Systemd can ship rules which e.g. apply device-specific metadata or give
/dev read access (like the various ID_FOO=1 hwdb.d rules), but it can't
really install rules which try to start external software that might or
might not be installed.


On Wed, Feb 25, 2026, 18:39 John G. Heim  wrote:

> I would like to make it possible for a blind Linux user to plug a
> hardware speech synth into a USB port and get speech w/o having to type
> anything.
>
> I think you can understand the motivation for this -- it is hard to type
> in a command to start speech if you don't have speech. It's like having
> to type in a command to turn on your monitor when your monitor isn't
> working.
>
> And  I know it's possible because I've done it by adding my own rules to
> /etc/udev/rules.d/.
>
> I've collected ID info for 3 hardware synths and  I can get more. What I
> need to know is what I have to do to get these rules into Linux proper.
>
> Of course, I am willing to do all the work. I just need direction.
>
>
>
>
>