Re: another input/output question (libinput / pulseaudio / ....)
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). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: another input/output question (libinput / pulseaudio / ....)
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 bnoc...@redhat.com: - 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: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/media-keys/gsd-media-keys-manager.c#n1184 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: another input/output question (libinput / pulseaudio / ....)
On Tue, Feb 10, 2015 at 02:09:55PM -0500, Matthias Clasen wrote: 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). I _think_ we do that but I'm open to suggestions if we don't do it sufficiently. First, all events in libinput are device-based. There are some seat helpers but all events are still per libinput device, so you definitely know which device the event is coming from. Right now, the only real thing to associate with any topology you get from libinput is the udev_device. What's in the works for 0.11 are device groups (see http://who-t.blogspot.com.au/2015/02/libinput-device-groups.html) which give you a bit more of the topology in some special cases, though that probably won't apply in this particular case. if there is anything more we should do pls let us know. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: another input/output question (libinput / pulseaudio / ....)
- 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: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/media-keys/gsd-media-keys-manager.c#n1184 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: another input/output question (libinput / pulseaudio / ....)
On Fri, Feb 06, 2015 at 11:47:16AM +0100, Damian Ivanov wrote: Hello folks, I am happy owner of a Razer 7.1 Chroma Headset (my girlfriend makes the right presents :)) There are various issues with this product as well as with some devices in general. I can of course open separate bug reports for each issue (if needed) 1) As I tried rawhide today with xorg-x11-drv-libinput I noticed that the Headset is listed as input device type: keyboard;map:us; I guess that's because it has a mute button on the retractable micro (suggestion: libinput type:headset??) X itself doesn't know about anything but pointers and keyboards (after all, they comprised the vast majority of devices in the 80s :) So the best you can expect here is a different log message. 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. Cheers, Peter 2) In the sound settings it's only stereo listed as profile, it's a 7.1 headset (yes, I tried it on Windows and 7.1 headset is not only snake oil) It is really poorly documented how to get 7.1 working. 3) The chroma (razer) device series (keyboards,mice,headsets and others) have Led's on it which can change the color using the windows driver. The Led's work on Linux but there is no tool to change it. The chroma series are only the first of this type, more products from other companies seem to have/get such feature as well. If there was a backend that does changing the color is there any place in the gnome ui, where this could be placed (the chroma devices has mice/headsets/keyboards)? I have seen using wireshark and a VM how to reverse engineer what the driver does when changing the color. Question here: where would this go? A cmd tool? A seperate gui tools? Can this and if yes how be integrated to gnome-control-center? Thanks in advance for any input/output :) br, Damian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: another input/output question (libinput / pulseaudio / ....)
On 02/06/2015 02:47 AM, Damian Ivanov wrote: 2) In the sound settings it's only stereo listed as profile, it's a 7.1 headset (yes, I tried it on Windows and 7.1 headset is not only snake oil) It is really poorly documented how to get 7.1 working. This is either the kernel driver or ALSA. Useful information would be: 1. The chunk of device information from /proc/bus/input/devices 2. The chunk of information from lsusb -v. 3. The output from dmesg when you plug in the device. 3) The chroma (razer) device series (keyboards,mice,headsets and others) have Led's on it which can change the color using the windows driver. The Led's work on Linux but there is no tool to change it. The chroma series are only the first of this type, more products from other companies seem to have/get such feature as well. If there was a backend that does changing the color is there any place in the gnome ui, where this could be placed (the chroma devices has mice/headsets/keyboards)? I have seen using wireshark and a VM how to reverse engineer what the driver does when changing the color. Question here: where would this go? A cmd tool? A seperate gui tools? Can this and if yes how be integrated to gnome-control-center? A quick search gave me https://github.com/mbuesch/razer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
another input/output question (libinput / pulseaudio / ....)
Hello folks, I am happy owner of a Razer 7.1 Chroma Headset (my girlfriend makes the right presents :)) There are various issues with this product as well as with some devices in general. I can of course open separate bug reports for each issue (if needed) 1) As I tried rawhide today with xorg-x11-drv-libinput I noticed that the Headset is listed as input device type: keyboard;map:us; I guess that's because it has a mute button on the retractable micro (suggestion: libinput type:headset??) 2) In the sound settings it's only stereo listed as profile, it's a 7.1 headset (yes, I tried it on Windows and 7.1 headset is not only snake oil) It is really poorly documented how to get 7.1 working. 3) The chroma (razer) device series (keyboards,mice,headsets and others) have Led's on it which can change the color using the windows driver. The Led's work on Linux but there is no tool to change it. The chroma series are only the first of this type, more products from other companies seem to have/get such feature as well. If there was a backend that does changing the color is there any place in the gnome ui, where this could be placed (the chroma devices has mice/headsets/keyboards)? I have seen using wireshark and a VM how to reverse engineer what the driver does when changing the color. Question here: where would this go? A cmd tool? A seperate gui tools? Can this and if yes how be integrated to gnome-control-center? Thanks in advance for any input/output :) br, Damian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
