On Mon, Jul 11, 2011 at 7:14 PM, Peter Hutterer
<[email protected]> wrote:
> On Mon, Jul 11, 2011 at 09:49:29AM -0600, Erich Hoover wrote:
>> On Sun, Jul 10, 2011 at 6:08 PM, Peter Hutterer
>> <[email protected]>wrote:
>>
>> > ...
>> > > I pulled out three of the five models we have and they have the following
>> > > ids:
>> > > 0x005: HP tc1100 (has pen buttons)
>> > > 0x006: HP tc4200 (has pen buttons)
>> > > 0x004: HP 2710p (no pen buttons)
>> >
>> > What's the full PNPID string? I ask because I think 0x5 and 0x6 are already
>> > in use for some wacom tablets.
>> >
>>
>> If it's the string I think it is, it appears to be "WACF00X:00" (where X is
>> 5 or 6 for the tablets in question). These tablets aren't exactly new tech
>> - the tc1100 came out in something like 2004 - so I would expect that the
>> ids are already well known. Anyway, the packet sent when the button push
>> occurs is clearly very unique - so its not like some other action is going
>> to accidentally trigger this code.
>
> right, if it's appended by :00 that can actually be the unique identifier.
> AFAIK, all wacom tablets are WACf00X only.
>
>> > ...
>> > On a general basis: rather than trickery with magic bits, I'd be nicer to
>> > get a new set of BTN_... defines into the kernel. We can then use that in
>> > the driver without having to use hacks. For kernels that don't support it,
>> > we can still #define that with the same value. Makes sense?
>> >
>>
>> Yes, do you think these should be BTN_* or KEY_* defines?
>
> in this case, probably KEY_*.
Yeah, it if the button/key is meant to launch an app (even a GUI
config app) then KEY_'s are usually better choice because only those
can bind in easily to your desktop environment's keyboard shortcut
log.
>
>> For this particular use-case: there is a KEY_KEYBOARD already which may be
>> > suitable here (ask on linux-input) and I wonder if KEY_EDITOR would be
>> > suitable for the "writing tool" (whatever that is). There is no rotation
>> > button or key yet afaict.
If there is not an exact fit for the journal case or whatever "Q" is
then KEY_PROG1 is a pretty good choice for launching a random app. It
maps to an X visible key. Asking on linux-input is a good idea
though.
For my tablet netbook, I'm starting to look into the rotate issue
since it has a rotate button. I've gotten as far as seeing the
gnome-settings-daemon detects XF86RotateWindows to rotate the screen
(if I'm reading it right) and X has at least this for that value:
symbols/inet: key <I162> { [ XF86RotateWindows ] };
Jumping over to udev, I see these rules. F21 is a bad choice because
we are using that for touchpad toggle. Not sure about F24 though.
grep -i rotate /lib/udev/keymaps/*
acer-travelmate_c300:0x67 f24 # FIXME: rotate screen
lenovo-thinkpad_x200_tablet:0x6c direction # rotate screen
lenovo-thinkpad_x6_tablet:0x6C f21 # rotate
Jumping back to X:
grep -ri direction *
keycodes/evdev: <I161> = 161; // #define KEY_DIRECTION 153
symbols/inet:// key <I161> { [ ] }; // KEY_DIRECTION
Darn, off by 1! If that would have been I162 then KEY_DIRECTION would
probably work out of the box.
Probably I'll propose patches once I figure it out better.
Chris
>> >
>>
>> The "writing tool" button is originally intended to bring up a "journal"
>> (pen writing) program. On the newer models this button doesn't actually
>> exist, instead there is a button with a giant "Q" that is supposed to open a
>> GUI menu. So, we set this button to open the writing program to match the
>> older model - but it should probably have its own button code instead. Is
>> it correct to assume from the way this discussion is headed that these
>> buttons should really emit these keycodes rather than pad button pushes?
>
> yes, I think so. buttons are just that - buttons. They are labelled to some
> extent but most applications only treat them as numbered buttons (until XI2
> and button labelling becomes more prominently used client-side).
> keys are handled properly already. So IMO these buttons are essentially
> multi-media keys similar to the ones on many keyboards.
>
> that would save us a lot of work, fit nicely into the existing stack and
> should even make things work out-of-the box.
>
> Cheers,
> Peter
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Linuxwacom-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
>
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Linuxwacom-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
