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...
Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. ------------------------------------------------------------------------------ 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
