On 29/09/11 21:41 , Michal Suchanek wrote: > On 29 September 2011 13:16, Peter Hutterer<peter.hutte...@who-t.net> wrote: >> On 29/09/11 20:55 , Michal Suchanek wrote: >>> >>> On 29 September 2011 11:19, Peter Hutterer<peter.hutte...@who-t.net> >>> wrote: >>>> >>>> On Thu, Sep 29, 2011 at 10:49:40AM +0200, Michal Suchanek wrote: >>>>> >>>>> On 29 September 2011 07:52, Peter Hutterer<peter.hutte...@who-t.net> >>>>> wrote: > >>>> No, xinput is device-independent and supposed to be generic. Some >>>> functions >>>> that are not specific to the wacom driver have been moved to xinput. >>>> There's >>>> a use fo xsetwacom as a simpler interface. e.g. xsetwacom set<device> >>>> TabletDebugLevel 3 is a lot simpler than xinput set-prop "device name" >>>> "propery name" 3 1 (you also have to know each property in full) >>>> >>> >>> You have to know (or list) the property with either tool. I don't see >>> why it's set to 3 in xsetwacom and 3 1 in xinput. AFAICT xinput is >>> very capable of setting device-specific properties exposed by the >>> driver. >> >> not every configuration option maps to a single property. Some properties >> contain multiple options. e.g. the debug property contains TabletDebugLevel >> and ToolDebugLevel. In order to set either, you need to set all (that's how >> xinput set-prop currently works) >> >> Besides, xinput does not do range checking in the client, it will simply >> return BadValue to the caller. xsetwacom will provide useful debug messages >> and a slightly improved UI (e.g. allowing for "on" or "off" instead of 0/1) > > Maybe the fact that xinput does not provide useful debug messages is a > bug in xinput then.
uhm. have you read the X protocol specification? xinput sends off the property values. If they're good, nothing (visible to xinput) happens. If they're bad, xinput gets back a BadValue error that contains (iirc either the property or the invalid value, can't remember). xinput _cannot_ know why something is BadValue without knowing what the valid format, type and value range for a property is. And that requires driver-specific knowledge which xinput as generic tool doesn't have (and won't get). yes, the X protocol is bad for error reporting. we know that but we're stuck with it. > As a fallback tool I don't care that it uses a peculiar format for the > options so long as it is documented what format it is. > >> >> >>>>>> Much further down the line is the magic LED changes that we talked >>>>>> about in >>>>>> the other thread - changing the LED at the same time as all button >>>>>> assignments. >>>>> >>>>> I don't have a tablet with leds so I would not know how that works but >>>>> this looks like something very device specific that *does* belong to a >>>>> driver. Only the driver knows which led corresponds to which button. >>>> >>>> That's the thing, the LEDs do not correspond to a button. In the Win/OS X >>>> driver they represent button configurations (so you can switch between) >>>> but >>>> from a driver's POV they're just LEDs without semantic meaning.. >>> >>> What is configured on them? on/off? colors? labels? bitmaps? >>> >>> All but bitmaps can be set as properties I guess. >> >> The LEDs will (likely) be controlled two properties, one for on/off, one for >> luminance. >> >> The OLED properties are a list of pixmaps which contain the image data that >> is displayed on the OLEDs. >> >> > ... >>>> I disagree. Unless you're happy to install yet another daemon that >>>> monitors >>>> the device list and applies settings at runtime this won't happen. GNOME >>>> and >>>> KDE have different visions on which options to expose to the client as >>>> well >>>> so I don't think you can have a desktop-independent tool. >>> >>> The problem is that GNOME, KDE, XFCE and whatnot will have not only >>> different features but also different bugs in their Wacom control >>> panel implementation and some less rapidly developing DEs will have no >>> such panel at all. >>> >>> This is needless duplication of work, too. While some DEs might strive >>> to provide a control panel for everything including the kitchen sink >>> some don't even attempt that and would rather rely on native tools. >> >> so what is your suggestion then? For a _graphical_ tool? GTK? Qt? Motif? TCL >> (please not, wacomcpl was bad enough) >> >>> Look at keyboard layout configuration which is much more common than >>> Wacom tablet configuration. Most DEs do provide a panel for that by >>> now but the gnome panel would often fail for me when upgrading to new >>> X version. On the inside it uses XKB which can be used from the >>> command line, too. And you can use xkbcomp directly when the GUI tools >>> fail or want some debug output they don't provide or just don't want >>> to install tens or hundreds of megabytes of UI libraries just to set >>> up your keyboard layout. Without xkbcomp xkb would be quite sad. >> >> Without xkbcomp, xkb wouldn't work. It's the parser, the server uses it too, >> so much that the server will refuse to start if xkbcomp cannot be found. >> >> Other than that, you've pretty much just described what GUIs are about. Take >> some things away to make it easier, at the cost of losing debug-ability. We >> could all still format our disks with fdisk but I for one enjoy the click >> click done during the anaconda install process. Same with NetworkManager and >> heaps of other tools. >> >> Don't get me wrong, I'd love to have the one generic GUI tool for >> configuring Wacom tablets that integrates nicely with any desktop >> environment. I just don't see it happen. >> > > Does it need to bu a GUI tool? yes. This isn't really up for discussion, we're well past the day where command-line tools alone were enough. > I mean there *should* be a tool that tests all features of the tablet > library and tablets. > > If it is designed with some minimum usability in mind and documented > it can be both used to test that the library works properly and used > as fallback when the DE tools don't work as expected or are missing. that brings us back to the library I mentioned. If you want to write a CLI tool to access the driver, you'll be much better off having it as a simple wrapper around the client library. But that one needs to be written first. Also, just to clarify this again: xsetwacom will stay around. It just won't get any of the fancier features, it'll be a driver setting tool and that's it. Cheers, Peter ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
