On Mon, Oct 1, 2012 at 6:56 AM, Olivier Fourdan <ofour...@redhat.com> wrote:
> Hi Jason,
>
> Jason Gerecke said the following on 09/28/2012 06:38 PM:
>
> But trying to fix like that raised another issue, as touchstrips LED are
>> inverted [3] on Cintiq, so what works in reality is:
>>
>> - First ring => /sys/bus/usb/devices/.../wacom_led/status_led0_select
>> - Second ring => /sys/bus/usb/devices/.../wacom_led/status_led1_select
>> - First touchstrip =>
>> /sys/bus/usb/devices/.../wacom_led/status_led1_select
>> - Second touchstrip =>
>> /sys/bus/usb/devices/.../wacom_led/status_led0_select
>>
>
> Even that patch is wrong, unfortunately. As noted in both the kernel's
> ABI docs and the libwacom datafiles, it should be as follows:
>
> Intuos4 (only [left] ring): => status_led0_select
> Intuos5 (only [left] ring): => status_led0_select
> Cintiq 21UX2 (left strip): => status_led1_select
> Cintiq 21UX2 (right strip): => status_led0_select
> Cintiq 22HD (left strip) => NO LEDs
> Cintiq 22HD (right strip) => NO LEDs
> Cintiq 24HD (left ring): => status_led1_select
> Cintiq 24HD (right ring): => status_led0_select
> Cintiq 24HD touch (left ring): => status_led1_select
> Cintiq 24HD touch (right ring): => status_led0_select
>
> Though its not a /documented/ rule, the behavior can be summed up as
> follows: if a device has only one ring/strip, use status_led0_select;
> otherwise the left ring/strip is controlled by status_led1_select and
> the right ring/strip by status_led0_select.
>
>> But that patch was denied and the consensus reached was that such hardware
>> implementation details should be hidden from userland apps
>>
>> So we need to fix the kernel to get:
>>
>> - First ring => /sys/bus/usb/devices/.../wacom_led/status_led0_select
>> - Second ring => /sys/bus/usb/devices/.../wacom_led/status_led1_select
>> - First touchstrip =>
>> /sys/bus/usb/devices/.../wacom_led/status_led0_select
>> - Second touchstrip =>
>> /sys/bus/usb/devices/.../wacom_led/status_led1_select
>>
>> independently of the hardware.
>>
>
> I talked more with Ping yesterday, and I'm not sure if its something
> that can really be fixed. The odd behavior is documented, which means
> its not a bug. A fix then would fall under the category of kernel API
> change, which can only be done for "grave errors or security problems"
> (i.e., not bad API choice). Because the interface has been upstream
> for a year now (almost to the day) which means there's likely
> non-GNOME code out there using it -- "fixing" the kernel would thus
> break existing applications.
>
> The only real solution I see is to create a new API that makes more
> sense, like what Przemo is trying to do for the OLEDs. Even that's not
> a perfect solution (more maintenance work in the kernel), but its not
> the quagmire that tweaking what already exists is.
>
>
> So I am now rewriting the patch for GNOME bug 676558 [1] using the logic
> above.
>
> Reading g-s-d code, it is assumed that if there is only one ring, it's on
> the left and if there are two, first one is on the left and second one on
> the right [2]:
>
> static GList *
> gsd_wacom_device_add_ring_modes (...)
> {
> ...
> if ((direction & WACOM_BUTTON_POSITION_LEFT) && libwacom_has_ring
> (wacom_device)) {
> ...
> } else if ((direction & WACOM_BUTTON_POSITION_RIGHT) &&
> libwacom_has_ring2 (wacom_device)) {
> ...
> }
> ...
> }
>
> Same for strip, if there's only one it is assumed to be on the left whereas
> if there are two, the first one is on the left and second one on the right
> [3]:
>
> static GList *
> gsd_wacom_device_add_strip_modes (...)
> {
> ...
> if ((direction & WACOM_BUTTON_POSITION_LEFT) && num_strips >= 1) {
> ....
> } else if ((direction & WACOM_BUTTON_POSITION_RIGHT) && num_strips
>>= 2) {
> ....
> }
> ....
> }
>
> Can you confirm if that's always the case? libwacom API does not seem
> particularly clear on this.
>
> Cheers,
> Olivier
>
> --
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=676558
> [2]
> http://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/wacom/gsd-wacom-device.c#n996
> [3]
> http://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/wacom/gsd-wacom-device.c#n1031
All the hardware I'm aware of has the "first' strip/ring is on the
left and the "second" on the right. Note that here "first touchstrip"
should be understood as "that touchstrip whose data is provided from
the kernel in ABS_RX", the second strip ABS_RY, the first ring
ABS_WHEEL, and the second ring ABS_THROTTLE.
It should be noted though that I'm not positive my own definition
matches that of libwacom -- Peter and Bastien are responsible for much
of the API. However, I did write all the Intuos/Cintiq datafiles with
that definition in mind, and I imagine that was the unstated
assumption in Peter's and Bastien's as well.
Jason
---
When you're rife with devastation / There's a simple explanation:
You're a toymaker's creation / Trapped inside a crystal ball.
And whichever way he tilts it / Know that we must be resilient
We won't let them break our spirits / As we sing our silly song.
------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
