another input/output question (libinput / pulseaudio / ....)

Damian Ivanov damianatorrpm at
Wed Feb 11 07:17:07 UTC 2015

Hello Bastien,
Hello list,

>I have no idea how to change the LEDs though, but if they're exposed in sysfs, you'd probably
>change them in gnome-settings-daemon as well.
I have :)
I will (in the next month) find out using virtualbox/vmware and a
packet sniffer see what the win driver is doing
while changing the LED's, so patches required: ok,
but where would be a proper place in the gnome gui for that?

2015-02-11 0:36 GMT+01:00 Bastien Nocera <bnocera at>:
> ----- Original Message -----
>> On Mon, 2015-02-09 at 08:44 +1000, Peter Hutterer wrote:
>> > However, especially for libinput, it gets hazy and also mostly pointless.
>> > aside from some special processing required for touchpads and tablets, we
>> > don't care much _what_ a device is, we just pass on the events.  If a
>> > device
>> > has keys, it'll be a keyboard. if it sents KEY_MUTE we pass that on, the
>> > compositor/X stack will then handle that however need be. There's no real
>> > benefit to us trying to figure out what is a headset and what isn't, we'd
>> > still just pass on the keys.
>> Fair enough. One thing that is important, though, is to preserve enough
>> information about the originating device (and the general device
>> topology) that higher levels have a chance to do the right thing (e.g.
>> mute the headset and not the speakers, if that is where the mute button
>> is).
> We already do that, when we can match the audio device with the input device,
> in gnome-settings-daemon:
> It did work to make the volume buttons on a USB speaker control the USB speaker and nothing else.
> I have no idea how to change the LEDs though, but if they're exposed in sysfs, you'd probably
> change them in gnome-settings-daemon as well.
> I'd say "patches welcome" but in this case it will be "patches required".
> --
> devel mailing list
> devel at
> Fedora Code of Conduct:

More information about the devel mailing list