On Mon, Jan 23, 2012 at 05:26:55PM -0800, Jason Gerecke wrote: > On Mon, Jan 23, 2012 at 3:36 PM, Peter Hutterer > <peter.hutte...@who-t.net> wrote: > > On Mon, Jan 23, 2012 at 10:30:34AM -0800, Jason Gerecke wrote: > >> On Sun, Jan 22, 2012 at 8:49 PM, Peter Hutterer > >> <peter.hutte...@who-t.net> wrote: > >> > On Fri, Jan 20, 2012 at 10:55:59AM -0800, Jason Gerecke wrote: > >> >> On Thu, Jan 19, 2012 at 8:12 PM, Peter Hutterer > >> >> <peter.hutte...@who-t.net> wrote: > >> >> > CC-ing Eduard, since he's been working on this as well > >> >> > > >> >> > On Wed, Jan 18, 2012 at 08:15:47PM -0600, Chris Bagwell wrote: > >> >> >> Well, this showed up just in time for me to be conflicted. I've > >> >> >> completed support for monitoring the battery on wireless bamboo's and > >> >> >> thinking about adding support to control powersavings timeout period > >> >> >> like Windows driver has. Its kinda a waste unless there is a GUI to > >> >> >> go with it though. > >> >> >> > >> >> >> Since sysfs is only read/write by root, we need to overcome that. I > >> >> >> was going to make a python daemon that advertises wacom sysfs changes > >> >> >> on DBUS and supports modifying timeout via DBUS requests. Then add > >> >> >> some sort of applet GUI for end users that talks over DBUS. > >> >> >> > >> >> >> Well, you've provided an interesting alternative to DBUS. It solves > >> >> >> the root issue and if we could somehow do a select() on the sysfs > >> >> >> then > >> >> >> I could monitor for battery changes as well and advertise changes as > >> >> >> property updates. > >> >> >> > >> >> >> For me, its probably the same amount of total code either way. I > >> >> >> need > >> >> >> to decide on if its appropriate to put these type of features into > >> >> >> xf86-input-wacom. > >> >> >> > >> >> >> I'm more comfortable working with DBUS then X properties (says the > >> >> >> guy > >> >> >> working on X drivers :-) ) so probably why I chose it. > >> >> >> > >> >> >> I probably only have 1 code comment beyond a general concern if this > >> >> >> is a feature we should be support (I'd like to hear others opinions). > >> >> >> See below. > >> >> > > >> >> > the reason why I'd like to see this as a property is simple: graphical > >> >> > applications already communicate with the X server for events and > >> >> > thus have > >> >> > device-specific knowledge (XI/XI2 applications anyway). I consider > >> >> > the LED > >> >> > just as an additional feature on the device, so controlling it > >> >> > through a > >> >> > device property seems to make sense. > >> >> > > >> >> > Otherwise a client would have to figure out which device it is that > >> >> > needs > >> >> > the LED changed, hook up to sysfs (or some custom daemon). Said > >> >> > daemon would > >> >> > need to provide notification systems (if more than one client access > >> >> > the > >> >> > LED), etc. All this infrastructure is already there in X, even if it > >> >> > may not > >> >> > necessarily be the sanest infrastructure.. > >> >> > > >> >> > Comments regarding the patch itself are in a separate email. > >> >> > > >> >> > Cheers, > >> >> > Peter > >> >> > > >> >> This is actually kind of what I thought you were getting at the first > >> >> time you mentioned the idea of libwacom to me. An intermediary library > >> >> that takes the ugly out of working directly with the X properties that > >> >> we expose. Combined with a deep knowledge of the actual tablet, > >> >> clients could do some really neat things without having to duplicate > >> >> code. For example, it'd be awesome if clients could find out (or > >> >> libwacom somehow handled) the Intuos4's quirk where the first button > >> >> in the X properties is *not* the top-left button. > >> > > >> > refresh my memory: is this a bug or a feature? > >> > if it's a bug, I'd argue for not worrying about it too much, otherwise > >> > we'll > >> > just end up in ifdef hell. > >> > > >> While it'd be great if the driver made the hardware appear more > >> consistent, I really don't see that happening. Our X properties don't > >> carry enough semantic information to make it possible to (sanely) > >> handle quirks like button 1 on the Intuos4, and radically changing > >> them would just make the driver needlessly complex while > >> simultaneously breaking compatibility. Its not the fault of the driver > >> that button 1 is weird -- that's just the way the hardware *is*. There > >> should be a way for interested clients to learn about and deal with > >> these quirks, and going through the X server is not the answer. > >> Libwacom *may* be the answer (since they share a lot of common > >> ground), but it also might not be... I'm just mulling over the idea > >> out loud :) > > > > right, it's a question of abstraction and where do we put it and there is no > > single right answer and we have to draw the line for sanity somewhere. > > > > for the button issue: imo the driver should expose all buttons identically, > > but knowing which button is where is up to the client (with the help from > > libwacom or the user). anything beyond that is nasty, as you said. > > > > though even with libwacom I expect _some_ stuff will always be user- or > > client-specific knowledge that cannot be abstracted in a library. > > > >> >> Of course, the devil's in figuring out how to represent those quirks > >> >> (both to libwacom in its config files, and to clients via the API)... > >> > > >> > some of it is true. yes, I want libwacom to be a convenience library so > >> > that > >> > clients don't have to poke at properties around. Nonetheless, the above > >> > is > >> > still true - the client that has to do all the work would just be > >> > libwacom > >> > (plus any client not using it). > >> > > >> >> Or the quirk that > >> >> the 24HD can actually turn off all the LEDs in a bank since it only > >> >> has 3 of the expected 4 LEDs. > >> > > >> > other tablets can't turn off all LEDs? > >> > > >> That's correct. I'm not sure if future tablets will be like the 24HD > >> and let you turn them off, but the I4 and 21UX2 have no "off" option > >> I'm aware of. You might be able to fake it by setting the active and > >> inactive luminosity to zero, but I'm not sure if zero is really "off" > >> or just "dim". > > > > ok, so next question: can we turn on all LEDs or can it only be one at a > > time? if we can't really turn them all on/off willy-nilly, I really think > > that a proper LED class would be the better option than a property with too > > much context. > > > > Cheers, > > Peter > > > > > At the moment its a one-at-a-time affair. The hardware isn't capable > of having multiple LEDs within a single bank lit (that, or the > firmware doesn't expose the functionality). I'm not sure what the > future will bring, but suppose its possible we could eventually come > out with something more flexible. I know, for instance, that some MIDI > controllers have buttons with embedded LEDs that software can control > independently from one another (its not a tablet, admittedly, but I've > got MIDI controllers on the mind :D) What are the pros and cons of > going with an LED feedback class? My google searches aren't turning up > too much information at the moment...
Have a look at the XI 1.x protocol spec (search for LedFeedbackState) http://cgit.freedesktop.org/xorg/proto/inputproto/tree/specs/XIproto.txt#n1699 This is rather limited since it only allows binary states (if I read this correctly) but for a future XI 2.3 addition this could be more complex, or at least with more informative errors. Without having thought too much about it, a class could contain information about the range of an LED, the number of LEDs and policies on setting LEDs. think of something like this LEDCLASS { type: ButtonClass length: CARD16 sourceid: CARD16 led_min_set: CARD16 /* min number of LEDs alight */ led_max_set: CARD16 /* max number of LEDs alight */ led_len: CARD16 /* number of LEDs */ led_min_range: CARD32 /* min value per LED */ led_max_range: CARD32 /* max value per LED */ labels: LISTofATOM /* names */ state: LISTofCARD32 /* actual values */ } something like this, anyway. Plus protocol requests to change various things. Cheers, Peter ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
