Peter Hutterer <peter.hutterer@...> writes: > On Wed, Feb 08, 2012 at 08:30:58AM -0800, Jason Gerecke wrote: > > Any feedback on the changes or ideas on exposing the properties? > > sorry for the delay. short answer - I don't think we should merge this > support as properties. properties are not well-suited for this, they are too > generic and too much knowledge must reside in the client setting them.
Exactly. But the client should be the one handling the mode switching, and the button actions in the first place. So I don't see what's wrong with exposing it as a property. It would make it available now, and make it possible for me to make the mode switching work in GNOME 3.4 (I really don't want to have mode switching enabled if I can't show the user that the mode has indeed switched). So I'm in favour of one property per LED group, and a bitmask as to which one is lit up (if even just an index, if we want to force 1 LED lit at all times). > Instead, we should extend the protocol for XI 2.3 to add a LED class and the > required requests to modify the LEDs support. This gives us > more flexibility handling LEDs and less driver-dependent behaviour. That's nice. It doesn't require using properties. but it does still require the client having special knowledge of the device. It's not like one would set the LEDs the same way on a Wacom tablet and a PS3 joypad for example. Cheers ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
