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: >>>> This is a heads-up, a brain storming and ideas collection all at the >>>> same time. >>>> >>>> xsetwacom is the previously small utility to tweak random driver functions. >>>> This is what this tool should remain as. I'm happy to add any new driver >>>> feature but I don't want semantic patches to filter into xsetwacom. It is >>>> not designed for it and it would screw up the usability by a lot. >>> >>> What does xsetwacom do that xinput does not? >> >> some parts are overlapping (MapToOutput and button mapping) but most >> functions that xsetwacom supports are driver-specific and to some extent >> even driver-version specific. That's why xsetwacom is part of the driver >> package. >> >>> Should not xinput be fixed to to manage all devices including wacom tablets? >> >> 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) >>>> 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. >>>> This isn't to say that such a tool cannot exist but it won't be xsetwacom >>>> and it won't be in the xf86-input-wacom repository. This is a driver. >>>> >>>> Jason and I talked about the need for a client-side library at XDC and the >>>> possible need for another cli tool to change wacom driver settings. I >>>> certainly agree with the client-side library, we need the ability for >>>> clients to query e.g. model numbers and features. As for the commandline >>>> tool - I think the correct integration will be in the desktops, not bolted >>>> onto various commandline tools. But I'm certainly not going to stop anyone >>>> from implementing it. >>> >>> So will I need to, say, install gnome-control-center to figure out the >>> tool number of my wacom tools in KDE or XFCE? >> >> no, you get KDE or XFCE to update their configuration utilities to cater for >> wacom tablets as well. Each desktop has different requirements and thus >> requires different configuration tools. >> >>> Does not sound like the way to go. >>> >>> The tools required to set up and test the tablet should be >>> desktop-independent. >> >> 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. 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
