Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Dnia 2014-07-25, pią o godzinie 19:15 -0400, Benjamin Tissoires pisze: > [..] Hi Bejnamin, > > I don't remember for sure, but I think the range of brightness might be > > different > > over usb and over bluetooth. > > Maybe you can try setting the sysfs file "buttons_luminance" with the > value 8 to check if this will solve the bug. No, that doesn't make any difference. > The bug might also be linked to the slight difference while setting up > the transfer of the image (WAC_CMD_ICON_START) with the value of buf[1] > set to 1 in USB, while it was 0 on bluetooth. > > The weird thing is that I remembered having set the OLED (though > scrambled) with these patches applied. I guess the scrambling was due to > the 4-bit vs 1-bit. But I definitively had some results. I spotted something: hid-wacom:c (before modifications) #define WAC_CMD_ICON_TRANSFER 0x26 wacom_sys.c: (after modifications) #define WAC_CMD_ICON_XFER 0x23 Changing it fixes the problem. Patches to follow soon. -- Kind regards, Przemo Firszt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Dnia 2014-07-25, pią o godzinie 19:15 -0400, Benjamin Tissoires pisze: [..] Hi Bejnamin, I don't remember for sure, but I think the range of brightness might be different over usb and over bluetooth. Maybe you can try setting the sysfs file buttons_luminance with the value 8 to check if this will solve the bug. No, that doesn't make any difference. The bug might also be linked to the slight difference while setting up the transfer of the image (WAC_CMD_ICON_START) with the value of buf[1] set to 1 in USB, while it was 0 on bluetooth. The weird thing is that I remembered having set the OLED (though scrambled) with these patches applied. I guess the scrambling was due to the 4-bit vs 1-bit. But I definitively had some results. I spotted something: hid-wacom:c (before modifications) #define WAC_CMD_ICON_TRANSFER 0x26 wacom_sys.c: (after modifications) #define WAC_CMD_ICON_XFER 0x23 Changing it fixes the problem. Patches to follow soon. -- Kind regards, Przemo Firszt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
On Fri, Jul 25, 2014 at 11:21:27PM -0400, Benjamin Tissoires wrote: > On Jul 25 2014 or thereabouts, Dmitry Torokhov wrote: > > Hi Benjamin, > > > > On Thu, Jul 24, 2014 at 02:13:55PM -0400, Benjamin Tissoires wrote: > > > Hi Dmitry, > > > > > > this is the second series I told you about for wacom.ko. This series also > > > have > > > a good number of removed lines of code. \o/ > > > > > > The first patch is Jason's one that I finally decided to take with me. His > > > previous submission still applied correctly even after the moving of the > > > files > > > (git is definitively awesome). > > > > > > The second one is a patch I sent earlier and forgot to include in the v2 > > > of > > > the first series. It might have been dropped during my many rebases. So > > > here > > > he is. > > > > > > The rest is for one part enhancing the battery reporting system (to make > > > it > > > equal to the one in hid-wacom, and even slightly better). The other part > > > is the actual merge of hid-wacom into wacom which gives the same user > > > space API > > > for bluetooth and USB devices, fixes the pad-in-a-separate-input-dev, and > > > fixes the missing tools not supported in the previous implementation of > > > hid-wacom for Intuos 4 BT. > > > > > > > I ended up taking 3.16-rc6 and applying your first series and the first > > 5 patches of this series to it. You should be able to see the result on > > kernel.org in wacom branch. > > Cool. The resolution of the hid-core.c conflict is in fact better than > what I proposed. It should not conflict with Jiri's pull request IMO. And > when the two branches will hit Linus' we can then un-split hid-rmi and > wacom processes. > > I also noticed few differences. Some of them you obviously made, I am > fine with them BTW, and some other I think because your current next > branch already has some wacom patches queued. I guess you will handle > this just fine, as usual, but I'll try to keep an eye on it just in case > git messed up the merge and forgot one branch. > > Thanks again Dmitry. And sorry for have pushed you regarding that. No worries, I need to be pushed sometimes ;) -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
On Jul 25 2014 or thereabouts, Dmitry Torokhov wrote: > Hi Benjamin, > > On Thu, Jul 24, 2014 at 02:13:55PM -0400, Benjamin Tissoires wrote: > > Hi Dmitry, > > > > this is the second series I told you about for wacom.ko. This series also > > have > > a good number of removed lines of code. \o/ > > > > The first patch is Jason's one that I finally decided to take with me. His > > previous submission still applied correctly even after the moving of the > > files > > (git is definitively awesome). > > > > The second one is a patch I sent earlier and forgot to include in the v2 of > > the first series. It might have been dropped during my many rebases. So here > > he is. > > > > The rest is for one part enhancing the battery reporting system (to make it > > equal to the one in hid-wacom, and even slightly better). The other part > > is the actual merge of hid-wacom into wacom which gives the same user space > > API > > for bluetooth and USB devices, fixes the pad-in-a-separate-input-dev, and > > fixes the missing tools not supported in the previous implementation of > > hid-wacom for Intuos 4 BT. > > > > I ended up taking 3.16-rc6 and applying your first series and the first > 5 patches of this series to it. You should be able to see the result on > kernel.org in wacom branch. Cool. The resolution of the hid-core.c conflict is in fact better than what I proposed. It should not conflict with Jiri's pull request IMO. And when the two branches will hit Linus' we can then un-split hid-rmi and wacom processes. I also noticed few differences. Some of them you obviously made, I am fine with them BTW, and some other I think because your current next branch already has some wacom patches queued. I guess you will handle this just fine, as usual, but I'll try to keep an eye on it just in case git messed up the merge and forgot one branch. Thanks again Dmitry. And sorry for have pushed you regarding that. Cheers, Benjamin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Hi Benjamin, On Thu, Jul 24, 2014 at 02:13:55PM -0400, Benjamin Tissoires wrote: > Hi Dmitry, > > this is the second series I told you about for wacom.ko. This series also have > a good number of removed lines of code. \o/ > > The first patch is Jason's one that I finally decided to take with me. His > previous submission still applied correctly even after the moving of the files > (git is definitively awesome). > > The second one is a patch I sent earlier and forgot to include in the v2 of > the first series. It might have been dropped during my many rebases. So here > he is. > > The rest is for one part enhancing the battery reporting system (to make it > equal to the one in hid-wacom, and even slightly better). The other part > is the actual merge of hid-wacom into wacom which gives the same user space > API > for bluetooth and USB devices, fixes the pad-in-a-separate-input-dev, and > fixes the missing tools not supported in the previous implementation of > hid-wacom for Intuos 4 BT. > I ended up taking 3.16-rc6 and applying your first series and the first 5 patches of this series to it. You should be able to see the result on kernel.org in wacom branch. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Hi Przemo,
On Jul 25 2014 or thereabouts, Przemo Firszt wrote:
> Dnia 2014-07-24, czw o godzinie 14:13 -0400, Benjamin Tissoires pisze:
> [..]
> Hi Benjamin,
> I'm testing the whole series including the OLED patch that's not on the
> list yet.
>
> Hardware: 2 x Intuos4 Wireless tested on usb and bluetooth until noted
> otherwise.
>
> What works:
> 1. Tablet in general, pressure, tilt, buttons etc.
> 2. Battery reporting (including gnome). The double wireless tablet bug
> is gone:
>
> $ ls /sys/class/power_supply/
> AC BAT0 wacom_ac_2 wacom_ac_3 wacom_battery_2 wacom_battery_3
>
> 3. Setting LED selector value
> 4. Setting LED selector brightness (default and pressed)
> 5. Rendering images to button displays works on usb ONLY.
>
> $ i4oled -d
> /sys/bus/hid/drivers/wacom/0003\:056A\:00BC.0009/wacom_led/button0_rawimg -t
> Linux
>
> On bluetooth writing image goes fine (no error), but there is nothing showing
> up,
> so I suspect the brightness of OLED displays is not set properly.
>
> That's the code before changes:
>
> led = wdata->led_selector | 0x04;
> buf = kzalloc(9, GFP_KERNEL);
> if (buf) {
> buf[0] = WAC_CMD_LED_CONTROL;
> buf[1] = led;
> buf[2] = value >> 2;
> buf[3] = value;
> /* use fixed brightness for OLEDs */
> buf[4] = 0x08;
> hid_hw_raw_request(hdev, buf[0], buf, 9, HID_FEATURE_REPORT,
>HID_REQ_SET_REPORT);
> kfree(buf);
> }
>
> I don't remember for sure, but I think the range of brightness might be
> different
> over usb and over bluetooth.
Maybe you can try setting the sysfs file "buttons_luminance" with the
value 8 to check if this will solve the bug.
The bug might also be linked to the slight difference while setting up
the transfer of the image (WAC_CMD_ICON_START) with the value of buf[1]
set to 1 in USB, while it was 0 on bluetooth.
The weird thing is that I remembered having set the OLED (though
scrambled) with these patches applied. I guess the scrambling was due to
the 4-bit vs 1-bit. But I definitively had some results.
Anyway. Przemo, Dmitry, can we consider that this *will* be fixed by
next week, and so we can apply the series for 3.17?
I will have the hardware next week and be able to figure out the
differences between the 2 communication modes.
>
> TL;DR: the only thing that needs to be fixed is image-over-bluetooth,
> probably caused by not
> setting or incorrect setting of OLED brightness.
Thanks for the extensive testings. I'll send the "OLED patch that's not
on the list yet" as a 11/10 so everybody can have a look.
Cheers,
Benjamin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Dnia 2014-07-24, czw o godzinie 14:13 -0400, Benjamin Tissoires pisze:
[..]
Hi Benjamin,
I'm testing the whole series including the OLED patch that's not on the
list yet.
Hardware: 2 x Intuos4 Wireless tested on usb and bluetooth until noted
otherwise.
What works:
1. Tablet in general, pressure, tilt, buttons etc.
2. Battery reporting (including gnome). The double wireless tablet bug
is gone:
$ ls /sys/class/power_supply/
AC BAT0 wacom_ac_2 wacom_ac_3 wacom_battery_2 wacom_battery_3
3. Setting LED selector value
4. Setting LED selector brightness (default and pressed)
5. Rendering images to button displays works on usb ONLY.
$ i4oled -d
/sys/bus/hid/drivers/wacom/0003\:056A\:00BC.0009/wacom_led/button0_rawimg -t
Linux
On bluetooth writing image goes fine (no error), but there is nothing showing
up,
so I suspect the brightness of OLED displays is not set properly.
That's the code before changes:
led = wdata->led_selector | 0x04;
buf = kzalloc(9, GFP_KERNEL);
if (buf) {
buf[0] = WAC_CMD_LED_CONTROL;
buf[1] = led;
buf[2] = value >> 2;
buf[3] = value;
/* use fixed brightness for OLEDs */
buf[4] = 0x08;
hid_hw_raw_request(hdev, buf[0], buf, 9, HID_FEATURE_REPORT,
HID_REQ_SET_REPORT);
kfree(buf);
}
I don't remember for sure, but I think the range of brightness might be
different
over usb and over bluetooth.
TL;DR: the only thing that needs to be fixed is image-over-bluetooth, probably
caused by not
setting or incorrect setting of OLED brightness.
--
Kind regards,
Przemo Firszt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
On Jul 25 2014 or thereabouts, Przemo Firszt wrote: > Dnia 2014-07-25, pią o godzinie 10:54 -0400, Benjamin Tissoires pisze: > > [..] > Hi Benjamin, > > > > > If I understand you correctly we cannot have the same entry point in > > > sysfs for OLEDs unless we can tell userspace somehow if the tablet is > > > conected over USB or over bluetooth. The hardware of Intuos4 Wireless > > > over bluetooth allows only 1-bit images. The same hardware over USB > > > allows 4-bit images. Formatting of the images is also completely > > > > Holy crap! I missed that. I did not noticed the 1-bit vs 4-bits > > difference :( > > > > > different and it's not "plain". Check [1] for usb and exisitng > > > hid-wacom.c/wacom_scramble function for bluetooth. > > > > Maybe I overlooked it, but I thought that in case of USB, the scrambling > > is done in user space, and in case of BT, the same scrambling made in the > > kernel. They looks very similar so I thought the user-space scramble for > > USB would have fit. However, the 4-bits/1-bits kills that assumption. > > You're correct - USB requires scrambling in the user space, but > scrambling for USB is different than for BT. Example of USB scramble is > here: https://github.com/PrzemoF/i4oled/blob/master/src/i4oled.c#L401 > > > > > > > If we want to make it consistent single entry on kernel level we > > > probably have to implement image conversion in the kernel. The user land > > > would always use 4-bit, plain formatted images and kernel driver would > > > convert them to 4-bit, wacom usb format or 1-bit wacom bluetooth format > > > depending on how the tablet is connected. > > > > > > The downside of this approach is that the user land wouldn't have 100% > > > control over 1-bit images for bluetooth as kernel would have to create > > > them from 4-bit images. > > > > The USB interface is *very* simple: > > - if incoming data != 1024 -> reject > > - forward everything to the device without in kernel treatment* > > > > How about just changing the expected size to 256 in case of a BT tablet, > > and let the user-space scramble in both cases and forward proper raw > > data? > > > > This way, user space will still have control over 1-bit vs 4-bits, and > > the changes required in the kernel will be small enough. > Sounds good to me. Bit more coding in gnome, but it's a small thing. yeah, gnome already scramble for USB, let's have it scramble for BT too :) > > > My concern is that I'd like to have this series in 3.17 and I will not > > have access to the hardware until next week :/ > > Having all of the user-spaces breakages in the same kernel release will > > I think simplify the user space work. > I agree. OK. > > P.S. Could you send me that set of 23 patches using git-send-email that > I should apply on top of linux-next? I got it from lkml, but there is > still something messed (fails on patch 09/23). Of course, if it's not a > problem for you :-) Sure, I can definitively do that. I also made a small patch to check for 1024 or 256 bits in OLEDs, so if you could give a try, that would be great. Cheers, Benjamin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Dnia 2014-07-25, pią o godzinie 10:54 -0400, Benjamin Tissoires pisze: > [..] Hi Benjamin, > > > If I understand you correctly we cannot have the same entry point in > > sysfs for OLEDs unless we can tell userspace somehow if the tablet is > > conected over USB or over bluetooth. The hardware of Intuos4 Wireless > > over bluetooth allows only 1-bit images. The same hardware over USB > > allows 4-bit images. Formatting of the images is also completely > > Holy crap! I missed that. I did not noticed the 1-bit vs 4-bits > difference :( > > > different and it's not "plain". Check [1] for usb and exisitng > > hid-wacom.c/wacom_scramble function for bluetooth. > > Maybe I overlooked it, but I thought that in case of USB, the scrambling > is done in user space, and in case of BT, the same scrambling made in the > kernel. They looks very similar so I thought the user-space scramble for > USB would have fit. However, the 4-bits/1-bits kills that assumption. You're correct - USB requires scrambling in the user space, but scrambling for USB is different than for BT. Example of USB scramble is here: https://github.com/PrzemoF/i4oled/blob/master/src/i4oled.c#L401 > > > > If we want to make it consistent single entry on kernel level we > > probably have to implement image conversion in the kernel. The user land > > would always use 4-bit, plain formatted images and kernel driver would > > convert them to 4-bit, wacom usb format or 1-bit wacom bluetooth format > > depending on how the tablet is connected. > > > > The downside of this approach is that the user land wouldn't have 100% > > control over 1-bit images for bluetooth as kernel would have to create > > them from 4-bit images. > > The USB interface is *very* simple: > - if incoming data != 1024 -> reject > - forward everything to the device without in kernel treatment* > > How about just changing the expected size to 256 in case of a BT tablet, > and let the user-space scramble in both cases and forward proper raw > data? > > This way, user space will still have control over 1-bit vs 4-bits, and > the changes required in the kernel will be small enough. Sounds good to me. Bit more coding in gnome, but it's a small thing. > My concern is that I'd like to have this series in 3.17 and I will not > have access to the hardware until next week :/ > Having all of the user-spaces breakages in the same kernel release will > I think simplify the user space work. I agree. P.S. Could you send me that set of 23 patches using git-send-email that I should apply on top of linux-next? I got it from lkml, but there is still something messed (fails on patch 09/23). Of course, if it's not a problem for you :-) -- Kind regards, Przemo Firszt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
On Jul 25 2014 or thereabouts, Przemo Firszt wrote: > Dnia 2014-07-25, pią o godzinie 08:58 -0400, Benjamin Tissoires pisze: > > Hi Przemo, > Hi Benjamin, > > On Jul 25 2014 or thereabouts, Przemo Firszt wrote: > > > Dnia 2014-07-24, czw o godzinie 14:13 -0400, Benjamin Tissoires pisze: > > > [..] > > > > Hi Przemo, > > > Hi Benjamin, > > > > Normally, this series contains all the bits of hid-wacom (except the > > > > custom > > > > LED/OLED API). Please tell me if I am missing anything and if you like > > > > the > > > > change. > > > > > > I can't cleanly apply your set yet to test it, so: > > > > Hmm, you need to apply the first series I sent on July 15th, on top of > > Dmitry's next branch. > > > > http://www.spinics.net/lists/linux-input/msg32385.html > > > OK, thnaks! > > > Acked-by: Przemo Firszt > > > > Thanks! > > > > > > > > What's your plan about LED/OLED API? > > > > I thought I would only preserve the current, wider used, LED/OLED API and > > just drop the one in hid-wacom. This way, g-s-d will access both > > bluetooth and USB the same way. > > > > My decision was mostly guided because the support of BT in g-s-d was > > only added recently (3.12 and backported to gnome 3.10 IIRC). And as > > soon as these patches hit Dmitry's tree, I'll send the g-s-d patches to > > fix all that. > > If I understand you correctly we cannot have the same entry point in > sysfs for OLEDs unless we can tell userspace somehow if the tablet is > conected over USB or over bluetooth. The hardware of Intuos4 Wireless > over bluetooth allows only 1-bit images. The same hardware over USB > allows 4-bit images. Formatting of the images is also completely Holy crap! I missed that. I did not noticed the 1-bit vs 4-bits difference :( > different and it's not "plain". Check [1] for usb and exisitng > hid-wacom.c/wacom_scramble function for bluetooth. Maybe I overlooked it, but I thought that in case of USB, the scrambling is done in user space, and in case of BT, the same scrambling made in the kernel. They looks very similar so I thought the user-space scramble for USB would have fit. However, the 4-bits/1-bits kills that assumption. > > If we want to make it consistent single entry on kernel level we > probably have to implement image conversion in the kernel. The user land > would always use 4-bit, plain formatted images and kernel driver would > convert them to 4-bit, wacom usb format or 1-bit wacom bluetooth format > depending on how the tablet is connected. > > The downside of this approach is that the user land wouldn't have 100% > control over 1-bit images for bluetooth as kernel would have to create > them from 4-bit images. The USB interface is *very* simple: - if incoming data != 1024 -> reject - forward everything to the device without in kernel treatment* How about just changing the expected size to 256 in case of a BT tablet, and let the user-space scramble in both cases and forward proper raw data? This way, user space will still have control over 1-bit vs 4-bits, and the changes required in the kernel will be small enough. My concern is that I'd like to have this series in 3.17 and I will not have access to the hardware until next week :/ Having all of the user-spaces breakages in the same kernel release will I think simplify the user space work. Cheers, Benjamin * speaking about that: I just noticed that hid-wacom sent the WAC_CMD_ICON_START_STOP message twice with 0 as the second parameter. However, the USB spec tells that you have to use 1 for 'start' and 0 for 'stop'. Rather weird that this is working with both 0 in BT mode. > > [1] https://lkml.org/lkml/2012/9/9/80 > -- > Kind regards, > Przemo Firszt > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Dnia 2014-07-25, pią o godzinie 08:58 -0400, Benjamin Tissoires pisze: > Hi Przemo, Hi Benjamin, > On Jul 25 2014 or thereabouts, Przemo Firszt wrote: > > Dnia 2014-07-24, czw o godzinie 14:13 -0400, Benjamin Tissoires pisze: > > [..] > > > Hi Przemo, > > Hi Benjamin, > > > Normally, this series contains all the bits of hid-wacom (except the > > > custom > > > LED/OLED API). Please tell me if I am missing anything and if you like the > > > change. > > > > I can't cleanly apply your set yet to test it, so: > > Hmm, you need to apply the first series I sent on July 15th, on top of > Dmitry's next branch. > > http://www.spinics.net/lists/linux-input/msg32385.html > OK, thnaks! > > Acked-by: Przemo Firszt > > Thanks! > > > > > What's your plan about LED/OLED API? > > I thought I would only preserve the current, wider used, LED/OLED API and > just drop the one in hid-wacom. This way, g-s-d will access both > bluetooth and USB the same way. > > My decision was mostly guided because the support of BT in g-s-d was > only added recently (3.12 and backported to gnome 3.10 IIRC). And as > soon as these patches hit Dmitry's tree, I'll send the g-s-d patches to > fix all that. If I understand you correctly we cannot have the same entry point in sysfs for OLEDs unless we can tell userspace somehow if the tablet is conected over USB or over bluetooth. The hardware of Intuos4 Wireless over bluetooth allows only 1-bit images. The same hardware over USB allows 4-bit images. Formatting of the images is also completely different and it's not "plain". Check [1] for usb and exisitng hid-wacom.c/wacom_scramble function for bluetooth. If we want to make it consistent single entry on kernel level we probably have to implement image conversion in the kernel. The user land would always use 4-bit, plain formatted images and kernel driver would convert them to 4-bit, wacom usb format or 1-bit wacom bluetooth format depending on how the tablet is connected. The downside of this approach is that the user land wouldn't have 100% control over 1-bit images for bluetooth as kernel would have to create them from 4-bit images. [1] https://lkml.org/lkml/2012/9/9/80 -- Kind regards, Przemo Firszt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Hi Przemo, On Jul 25 2014 or thereabouts, Przemo Firszt wrote: > Dnia 2014-07-24, czw o godzinie 14:13 -0400, Benjamin Tissoires pisze: > [..] > > Hi Przemo, > Hi Benjamin, > > Normally, this series contains all the bits of hid-wacom (except the custom > > LED/OLED API). Please tell me if I am missing anything and if you like the > > change. > > I can't cleanly apply your set yet to test it, so: Hmm, you need to apply the first series I sent on July 15th, on top of Dmitry's next branch. http://www.spinics.net/lists/linux-input/msg32385.html > > Acked-by: Przemo Firszt Thanks! > > What's your plan about LED/OLED API? I thought I would only preserve the current, wider used, LED/OLED API and just drop the one in hid-wacom. This way, g-s-d will access both bluetooth and USB the same way. My decision was mostly guided because the support of BT in g-s-d was only added recently (3.12 and backported to gnome 3.10 IIRC). And as soon as these patches hit Dmitry's tree, I'll send the g-s-d patches to fix all that. Cheers, Benjamin > > > Benjamin Tissoires (9): > > Input - wacom: put a flag when the led are initialized > > Input - wacom: enhance Wireless Receiver battery reporting > > Input - wacom: use a uniq name for the battery device > > Input - wacom: register an ac power supply for wireless devices > > Input - wacom: prepare the driver to include BT devices > > Input - wacom: handle Graphire BT tablets in wacom.ko > > Input - wacom: handle Intuos 4 BT in wacom.ko > > Input - wacom: add copyright note and bump version to 2.0 > > HID: remove hid-wacom Bluetooth driver > > > > Jason Gerecke (1): > > Input - wacom: Support up to 2048 pressure levels with ISDv4 > > > > drivers/hid/Kconfig | 10 +- > > drivers/hid/Makefile| 3 +- > > drivers/hid/hid-core.c | 2 - > > drivers/hid/hid-wacom.c | 973 > > > > drivers/hid/wacom.h | 11 + > > drivers/hid/wacom_sys.c | 217 ++- > > drivers/hid/wacom_wac.c | 195 +- > > drivers/hid/wacom_wac.h | 10 + > > 8 files changed, 415 insertions(+), 1006 deletions(-) > > delete mode 100644 drivers/hid/hid-wacom.c > > > > -- > Kind regards, > Przemo Firszt > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Dnia 2014-07-24, czw o godzinie 14:13 -0400, Benjamin Tissoires pisze: [..] > Hi Przemo, Hi Benjamin, > Normally, this series contains all the bits of hid-wacom (except the custom > LED/OLED API). Please tell me if I am missing anything and if you like the > change. I can't cleanly apply your set yet to test it, so: Acked-by: Przemo Firszt What's your plan about LED/OLED API? > Benjamin Tissoires (9): > Input - wacom: put a flag when the led are initialized > Input - wacom: enhance Wireless Receiver battery reporting > Input - wacom: use a uniq name for the battery device > Input - wacom: register an ac power supply for wireless devices > Input - wacom: prepare the driver to include BT devices > Input - wacom: handle Graphire BT tablets in wacom.ko > Input - wacom: handle Intuos 4 BT in wacom.ko > Input - wacom: add copyright note and bump version to 2.0 > HID: remove hid-wacom Bluetooth driver > > Jason Gerecke (1): > Input - wacom: Support up to 2048 pressure levels with ISDv4 > > drivers/hid/Kconfig | 10 +- > drivers/hid/Makefile| 3 +- > drivers/hid/hid-core.c | 2 - > drivers/hid/hid-wacom.c | 973 > > drivers/hid/wacom.h | 11 + > drivers/hid/wacom_sys.c | 217 ++- > drivers/hid/wacom_wac.c | 195 +- > drivers/hid/wacom_wac.h | 10 + > 8 files changed, 415 insertions(+), 1006 deletions(-) > delete mode 100644 drivers/hid/hid-wacom.c > -- Kind regards, Przemo Firszt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Dnia 2014-07-24, czw o godzinie 14:13 -0400, Benjamin Tissoires pisze: [..] Hi Przemo, Hi Benjamin, Normally, this series contains all the bits of hid-wacom (except the custom LED/OLED API). Please tell me if I am missing anything and if you like the change. I can't cleanly apply your set yet to test it, so: Acked-by: Przemo Firszt prz...@firszt.eu What's your plan about LED/OLED API? Benjamin Tissoires (9): Input - wacom: put a flag when the led are initialized Input - wacom: enhance Wireless Receiver battery reporting Input - wacom: use a uniq name for the battery device Input - wacom: register an ac power supply for wireless devices Input - wacom: prepare the driver to include BT devices Input - wacom: handle Graphire BT tablets in wacom.ko Input - wacom: handle Intuos 4 BT in wacom.ko Input - wacom: add copyright note and bump version to 2.0 HID: remove hid-wacom Bluetooth driver Jason Gerecke (1): Input - wacom: Support up to 2048 pressure levels with ISDv4 drivers/hid/Kconfig | 10 +- drivers/hid/Makefile| 3 +- drivers/hid/hid-core.c | 2 - drivers/hid/hid-wacom.c | 973 drivers/hid/wacom.h | 11 + drivers/hid/wacom_sys.c | 217 ++- drivers/hid/wacom_wac.c | 195 +- drivers/hid/wacom_wac.h | 10 + 8 files changed, 415 insertions(+), 1006 deletions(-) delete mode 100644 drivers/hid/hid-wacom.c -- Kind regards, Przemo Firszt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Hi Przemo, On Jul 25 2014 or thereabouts, Przemo Firszt wrote: Dnia 2014-07-24, czw o godzinie 14:13 -0400, Benjamin Tissoires pisze: [..] Hi Przemo, Hi Benjamin, Normally, this series contains all the bits of hid-wacom (except the custom LED/OLED API). Please tell me if I am missing anything and if you like the change. I can't cleanly apply your set yet to test it, so: Hmm, you need to apply the first series I sent on July 15th, on top of Dmitry's next branch. http://www.spinics.net/lists/linux-input/msg32385.html Acked-by: Przemo Firszt prz...@firszt.eu Thanks! What's your plan about LED/OLED API? I thought I would only preserve the current, wider used, LED/OLED API and just drop the one in hid-wacom. This way, g-s-d will access both bluetooth and USB the same way. My decision was mostly guided because the support of BT in g-s-d was only added recently (3.12 and backported to gnome 3.10 IIRC). And as soon as these patches hit Dmitry's tree, I'll send the g-s-d patches to fix all that. Cheers, Benjamin Benjamin Tissoires (9): Input - wacom: put a flag when the led are initialized Input - wacom: enhance Wireless Receiver battery reporting Input - wacom: use a uniq name for the battery device Input - wacom: register an ac power supply for wireless devices Input - wacom: prepare the driver to include BT devices Input - wacom: handle Graphire BT tablets in wacom.ko Input - wacom: handle Intuos 4 BT in wacom.ko Input - wacom: add copyright note and bump version to 2.0 HID: remove hid-wacom Bluetooth driver Jason Gerecke (1): Input - wacom: Support up to 2048 pressure levels with ISDv4 drivers/hid/Kconfig | 10 +- drivers/hid/Makefile| 3 +- drivers/hid/hid-core.c | 2 - drivers/hid/hid-wacom.c | 973 drivers/hid/wacom.h | 11 + drivers/hid/wacom_sys.c | 217 ++- drivers/hid/wacom_wac.c | 195 +- drivers/hid/wacom_wac.h | 10 + 8 files changed, 415 insertions(+), 1006 deletions(-) delete mode 100644 drivers/hid/hid-wacom.c -- Kind regards, Przemo Firszt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Dnia 2014-07-25, pią o godzinie 08:58 -0400, Benjamin Tissoires pisze: Hi Przemo, Hi Benjamin, On Jul 25 2014 or thereabouts, Przemo Firszt wrote: Dnia 2014-07-24, czw o godzinie 14:13 -0400, Benjamin Tissoires pisze: [..] Hi Przemo, Hi Benjamin, Normally, this series contains all the bits of hid-wacom (except the custom LED/OLED API). Please tell me if I am missing anything and if you like the change. I can't cleanly apply your set yet to test it, so: Hmm, you need to apply the first series I sent on July 15th, on top of Dmitry's next branch. http://www.spinics.net/lists/linux-input/msg32385.html OK, thnaks! Acked-by: Przemo Firszt prz...@firszt.eu Thanks! What's your plan about LED/OLED API? I thought I would only preserve the current, wider used, LED/OLED API and just drop the one in hid-wacom. This way, g-s-d will access both bluetooth and USB the same way. My decision was mostly guided because the support of BT in g-s-d was only added recently (3.12 and backported to gnome 3.10 IIRC). And as soon as these patches hit Dmitry's tree, I'll send the g-s-d patches to fix all that. If I understand you correctly we cannot have the same entry point in sysfs for OLEDs unless we can tell userspace somehow if the tablet is conected over USB or over bluetooth. The hardware of Intuos4 Wireless over bluetooth allows only 1-bit images. The same hardware over USB allows 4-bit images. Formatting of the images is also completely different and it's not plain. Check [1] for usb and exisitng hid-wacom.c/wacom_scramble function for bluetooth. If we want to make it consistent single entry on kernel level we probably have to implement image conversion in the kernel. The user land would always use 4-bit, plain formatted images and kernel driver would convert them to 4-bit, wacom usb format or 1-bit wacom bluetooth format depending on how the tablet is connected. The downside of this approach is that the user land wouldn't have 100% control over 1-bit images for bluetooth as kernel would have to create them from 4-bit images. [1] https://lkml.org/lkml/2012/9/9/80 -- Kind regards, Przemo Firszt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
On Jul 25 2014 or thereabouts, Przemo Firszt wrote: Dnia 2014-07-25, pią o godzinie 08:58 -0400, Benjamin Tissoires pisze: Hi Przemo, Hi Benjamin, On Jul 25 2014 or thereabouts, Przemo Firszt wrote: Dnia 2014-07-24, czw o godzinie 14:13 -0400, Benjamin Tissoires pisze: [..] Hi Przemo, Hi Benjamin, Normally, this series contains all the bits of hid-wacom (except the custom LED/OLED API). Please tell me if I am missing anything and if you like the change. I can't cleanly apply your set yet to test it, so: Hmm, you need to apply the first series I sent on July 15th, on top of Dmitry's next branch. http://www.spinics.net/lists/linux-input/msg32385.html OK, thnaks! Acked-by: Przemo Firszt prz...@firszt.eu Thanks! What's your plan about LED/OLED API? I thought I would only preserve the current, wider used, LED/OLED API and just drop the one in hid-wacom. This way, g-s-d will access both bluetooth and USB the same way. My decision was mostly guided because the support of BT in g-s-d was only added recently (3.12 and backported to gnome 3.10 IIRC). And as soon as these patches hit Dmitry's tree, I'll send the g-s-d patches to fix all that. If I understand you correctly we cannot have the same entry point in sysfs for OLEDs unless we can tell userspace somehow if the tablet is conected over USB or over bluetooth. The hardware of Intuos4 Wireless over bluetooth allows only 1-bit images. The same hardware over USB allows 4-bit images. Formatting of the images is also completely Holy crap! I missed that. I did not noticed the 1-bit vs 4-bits difference :( different and it's not plain. Check [1] for usb and exisitng hid-wacom.c/wacom_scramble function for bluetooth. Maybe I overlooked it, but I thought that in case of USB, the scrambling is done in user space, and in case of BT, the same scrambling made in the kernel. They looks very similar so I thought the user-space scramble for USB would have fit. However, the 4-bits/1-bits kills that assumption. If we want to make it consistent single entry on kernel level we probably have to implement image conversion in the kernel. The user land would always use 4-bit, plain formatted images and kernel driver would convert them to 4-bit, wacom usb format or 1-bit wacom bluetooth format depending on how the tablet is connected. The downside of this approach is that the user land wouldn't have 100% control over 1-bit images for bluetooth as kernel would have to create them from 4-bit images. The USB interface is *very* simple: - if incoming data != 1024 - reject - forward everything to the device without in kernel treatment* How about just changing the expected size to 256 in case of a BT tablet, and let the user-space scramble in both cases and forward proper raw data? This way, user space will still have control over 1-bit vs 4-bits, and the changes required in the kernel will be small enough. My concern is that I'd like to have this series in 3.17 and I will not have access to the hardware until next week :/ Having all of the user-spaces breakages in the same kernel release will I think simplify the user space work. Cheers, Benjamin * speaking about that: I just noticed that hid-wacom sent the WAC_CMD_ICON_START_STOP message twice with 0 as the second parameter. However, the USB spec tells that you have to use 1 for 'start' and 0 for 'stop'. Rather weird that this is working with both 0 in BT mode. [1] https://lkml.org/lkml/2012/9/9/80 -- Kind regards, Przemo Firszt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Dnia 2014-07-25, pią o godzinie 10:54 -0400, Benjamin Tissoires pisze: [..] Hi Benjamin, If I understand you correctly we cannot have the same entry point in sysfs for OLEDs unless we can tell userspace somehow if the tablet is conected over USB or over bluetooth. The hardware of Intuos4 Wireless over bluetooth allows only 1-bit images. The same hardware over USB allows 4-bit images. Formatting of the images is also completely Holy crap! I missed that. I did not noticed the 1-bit vs 4-bits difference :( different and it's not plain. Check [1] for usb and exisitng hid-wacom.c/wacom_scramble function for bluetooth. Maybe I overlooked it, but I thought that in case of USB, the scrambling is done in user space, and in case of BT, the same scrambling made in the kernel. They looks very similar so I thought the user-space scramble for USB would have fit. However, the 4-bits/1-bits kills that assumption. You're correct - USB requires scrambling in the user space, but scrambling for USB is different than for BT. Example of USB scramble is here: https://github.com/PrzemoF/i4oled/blob/master/src/i4oled.c#L401 If we want to make it consistent single entry on kernel level we probably have to implement image conversion in the kernel. The user land would always use 4-bit, plain formatted images and kernel driver would convert them to 4-bit, wacom usb format or 1-bit wacom bluetooth format depending on how the tablet is connected. The downside of this approach is that the user land wouldn't have 100% control over 1-bit images for bluetooth as kernel would have to create them from 4-bit images. The USB interface is *very* simple: - if incoming data != 1024 - reject - forward everything to the device without in kernel treatment* How about just changing the expected size to 256 in case of a BT tablet, and let the user-space scramble in both cases and forward proper raw data? This way, user space will still have control over 1-bit vs 4-bits, and the changes required in the kernel will be small enough. Sounds good to me. Bit more coding in gnome, but it's a small thing. My concern is that I'd like to have this series in 3.17 and I will not have access to the hardware until next week :/ Having all of the user-spaces breakages in the same kernel release will I think simplify the user space work. I agree. P.S. Could you send me that set of 23 patches using git-send-email that I should apply on top of linux-next? I got it from lkml, but there is still something messed (fails on patch 09/23). Of course, if it's not a problem for you :-) -- Kind regards, Przemo Firszt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
On Jul 25 2014 or thereabouts, Przemo Firszt wrote: Dnia 2014-07-25, pią o godzinie 10:54 -0400, Benjamin Tissoires pisze: [..] Hi Benjamin, If I understand you correctly we cannot have the same entry point in sysfs for OLEDs unless we can tell userspace somehow if the tablet is conected over USB or over bluetooth. The hardware of Intuos4 Wireless over bluetooth allows only 1-bit images. The same hardware over USB allows 4-bit images. Formatting of the images is also completely Holy crap! I missed that. I did not noticed the 1-bit vs 4-bits difference :( different and it's not plain. Check [1] for usb and exisitng hid-wacom.c/wacom_scramble function for bluetooth. Maybe I overlooked it, but I thought that in case of USB, the scrambling is done in user space, and in case of BT, the same scrambling made in the kernel. They looks very similar so I thought the user-space scramble for USB would have fit. However, the 4-bits/1-bits kills that assumption. You're correct - USB requires scrambling in the user space, but scrambling for USB is different than for BT. Example of USB scramble is here: https://github.com/PrzemoF/i4oled/blob/master/src/i4oled.c#L401 If we want to make it consistent single entry on kernel level we probably have to implement image conversion in the kernel. The user land would always use 4-bit, plain formatted images and kernel driver would convert them to 4-bit, wacom usb format or 1-bit wacom bluetooth format depending on how the tablet is connected. The downside of this approach is that the user land wouldn't have 100% control over 1-bit images for bluetooth as kernel would have to create them from 4-bit images. The USB interface is *very* simple: - if incoming data != 1024 - reject - forward everything to the device without in kernel treatment* How about just changing the expected size to 256 in case of a BT tablet, and let the user-space scramble in both cases and forward proper raw data? This way, user space will still have control over 1-bit vs 4-bits, and the changes required in the kernel will be small enough. Sounds good to me. Bit more coding in gnome, but it's a small thing. yeah, gnome already scramble for USB, let's have it scramble for BT too :) My concern is that I'd like to have this series in 3.17 and I will not have access to the hardware until next week :/ Having all of the user-spaces breakages in the same kernel release will I think simplify the user space work. I agree. OK. P.S. Could you send me that set of 23 patches using git-send-email that I should apply on top of linux-next? I got it from lkml, but there is still something messed (fails on patch 09/23). Of course, if it's not a problem for you :-) Sure, I can definitively do that. I also made a small patch to check for 1024 or 256 bits in OLEDs, so if you could give a try, that would be great. Cheers, Benjamin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Dnia 2014-07-24, czw o godzinie 14:13 -0400, Benjamin Tissoires pisze:
[..]
Hi Benjamin,
I'm testing the whole series including the OLED patch that's not on the
list yet.
Hardware: 2 x Intuos4 Wireless tested on usb and bluetooth until noted
otherwise.
What works:
1. Tablet in general, pressure, tilt, buttons etc.
2. Battery reporting (including gnome). The double wireless tablet bug
is gone:
$ ls /sys/class/power_supply/
AC BAT0 wacom_ac_2 wacom_ac_3 wacom_battery_2 wacom_battery_3
3. Setting LED selector value
4. Setting LED selector brightness (default and pressed)
5. Rendering images to button displays works on usb ONLY.
$ i4oled -d
/sys/bus/hid/drivers/wacom/0003\:056A\:00BC.0009/wacom_led/button0_rawimg -t
Linux
On bluetooth writing image goes fine (no error), but there is nothing showing
up,
so I suspect the brightness of OLED displays is not set properly.
That's the code before changes:
led = wdata-led_selector | 0x04;
buf = kzalloc(9, GFP_KERNEL);
if (buf) {
buf[0] = WAC_CMD_LED_CONTROL;
buf[1] = led;
buf[2] = value 2;
buf[3] = value;
/* use fixed brightness for OLEDs */
buf[4] = 0x08;
hid_hw_raw_request(hdev, buf[0], buf, 9, HID_FEATURE_REPORT,
HID_REQ_SET_REPORT);
kfree(buf);
}
I don't remember for sure, but I think the range of brightness might be
different
over usb and over bluetooth.
TL;DR: the only thing that needs to be fixed is image-over-bluetooth, probably
caused by not
setting or incorrect setting of OLED brightness.
--
Kind regards,
Przemo Firszt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Hi Przemo,
On Jul 25 2014 or thereabouts, Przemo Firszt wrote:
Dnia 2014-07-24, czw o godzinie 14:13 -0400, Benjamin Tissoires pisze:
[..]
Hi Benjamin,
I'm testing the whole series including the OLED patch that's not on the
list yet.
Hardware: 2 x Intuos4 Wireless tested on usb and bluetooth until noted
otherwise.
What works:
1. Tablet in general, pressure, tilt, buttons etc.
2. Battery reporting (including gnome). The double wireless tablet bug
is gone:
$ ls /sys/class/power_supply/
AC BAT0 wacom_ac_2 wacom_ac_3 wacom_battery_2 wacom_battery_3
3. Setting LED selector value
4. Setting LED selector brightness (default and pressed)
5. Rendering images to button displays works on usb ONLY.
$ i4oled -d
/sys/bus/hid/drivers/wacom/0003\:056A\:00BC.0009/wacom_led/button0_rawimg -t
Linux
On bluetooth writing image goes fine (no error), but there is nothing showing
up,
so I suspect the brightness of OLED displays is not set properly.
That's the code before changes:
led = wdata-led_selector | 0x04;
buf = kzalloc(9, GFP_KERNEL);
if (buf) {
buf[0] = WAC_CMD_LED_CONTROL;
buf[1] = led;
buf[2] = value 2;
buf[3] = value;
/* use fixed brightness for OLEDs */
buf[4] = 0x08;
hid_hw_raw_request(hdev, buf[0], buf, 9, HID_FEATURE_REPORT,
HID_REQ_SET_REPORT);
kfree(buf);
}
I don't remember for sure, but I think the range of brightness might be
different
over usb and over bluetooth.
Maybe you can try setting the sysfs file buttons_luminance with the
value 8 to check if this will solve the bug.
The bug might also be linked to the slight difference while setting up
the transfer of the image (WAC_CMD_ICON_START) with the value of buf[1]
set to 1 in USB, while it was 0 on bluetooth.
The weird thing is that I remembered having set the OLED (though
scrambled) with these patches applied. I guess the scrambling was due to
the 4-bit vs 1-bit. But I definitively had some results.
Anyway. Przemo, Dmitry, can we consider that this *will* be fixed by
next week, and so we can apply the series for 3.17?
I will have the hardware next week and be able to figure out the
differences between the 2 communication modes.
TL;DR: the only thing that needs to be fixed is image-over-bluetooth,
probably caused by not
setting or incorrect setting of OLED brightness.
Thanks for the extensive testings. I'll send the OLED patch that's not
on the list yet as a 11/10 so everybody can have a look.
Cheers,
Benjamin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Hi Benjamin, On Thu, Jul 24, 2014 at 02:13:55PM -0400, Benjamin Tissoires wrote: Hi Dmitry, this is the second series I told you about for wacom.ko. This series also have a good number of removed lines of code. \o/ The first patch is Jason's one that I finally decided to take with me. His previous submission still applied correctly even after the moving of the files (git is definitively awesome). The second one is a patch I sent earlier and forgot to include in the v2 of the first series. It might have been dropped during my many rebases. So here he is. The rest is for one part enhancing the battery reporting system (to make it equal to the one in hid-wacom, and even slightly better). The other part is the actual merge of hid-wacom into wacom which gives the same user space API for bluetooth and USB devices, fixes the pad-in-a-separate-input-dev, and fixes the missing tools not supported in the previous implementation of hid-wacom for Intuos 4 BT. I ended up taking 3.16-rc6 and applying your first series and the first 5 patches of this series to it. You should be able to see the result on kernel.org in wacom branch. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
On Jul 25 2014 or thereabouts, Dmitry Torokhov wrote: Hi Benjamin, On Thu, Jul 24, 2014 at 02:13:55PM -0400, Benjamin Tissoires wrote: Hi Dmitry, this is the second series I told you about for wacom.ko. This series also have a good number of removed lines of code. \o/ The first patch is Jason's one that I finally decided to take with me. His previous submission still applied correctly even after the moving of the files (git is definitively awesome). The second one is a patch I sent earlier and forgot to include in the v2 of the first series. It might have been dropped during my many rebases. So here he is. The rest is for one part enhancing the battery reporting system (to make it equal to the one in hid-wacom, and even slightly better). The other part is the actual merge of hid-wacom into wacom which gives the same user space API for bluetooth and USB devices, fixes the pad-in-a-separate-input-dev, and fixes the missing tools not supported in the previous implementation of hid-wacom for Intuos 4 BT. I ended up taking 3.16-rc6 and applying your first series and the first 5 patches of this series to it. You should be able to see the result on kernel.org in wacom branch. Cool. The resolution of the hid-core.c conflict is in fact better than what I proposed. It should not conflict with Jiri's pull request IMO. And when the two branches will hit Linus' we can then un-split hid-rmi and wacom processes. I also noticed few differences. Some of them you obviously made, I am fine with them BTW, and some other I think because your current next branch already has some wacom patches queued. I guess you will handle this just fine, as usual, but I'll try to keep an eye on it just in case git messed up the merge and forgot one branch. Thanks again Dmitry. And sorry for have pushed you regarding that. Cheers, Benjamin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
On Fri, Jul 25, 2014 at 11:21:27PM -0400, Benjamin Tissoires wrote: On Jul 25 2014 or thereabouts, Dmitry Torokhov wrote: Hi Benjamin, On Thu, Jul 24, 2014 at 02:13:55PM -0400, Benjamin Tissoires wrote: Hi Dmitry, this is the second series I told you about for wacom.ko. This series also have a good number of removed lines of code. \o/ The first patch is Jason's one that I finally decided to take with me. His previous submission still applied correctly even after the moving of the files (git is definitively awesome). The second one is a patch I sent earlier and forgot to include in the v2 of the first series. It might have been dropped during my many rebases. So here he is. The rest is for one part enhancing the battery reporting system (to make it equal to the one in hid-wacom, and even slightly better). The other part is the actual merge of hid-wacom into wacom which gives the same user space API for bluetooth and USB devices, fixes the pad-in-a-separate-input-dev, and fixes the missing tools not supported in the previous implementation of hid-wacom for Intuos 4 BT. I ended up taking 3.16-rc6 and applying your first series and the first 5 patches of this series to it. You should be able to see the result on kernel.org in wacom branch. Cool. The resolution of the hid-core.c conflict is in fact better than what I proposed. It should not conflict with Jiri's pull request IMO. And when the two branches will hit Linus' we can then un-split hid-rmi and wacom processes. I also noticed few differences. Some of them you obviously made, I am fine with them BTW, and some other I think because your current next branch already has some wacom patches queued. I guess you will handle this just fine, as usual, but I'll try to keep an eye on it just in case git messed up the merge and forgot one branch. Thanks again Dmitry. And sorry for have pushed you regarding that. No worries, I need to be pushed sometimes ;) -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Hi Dmitry, this is the second series I told you about for wacom.ko. This series also have a good number of removed lines of code. \o/ The first patch is Jason's one that I finally decided to take with me. His previous submission still applied correctly even after the moving of the files (git is definitively awesome). The second one is a patch I sent earlier and forgot to include in the v2 of the first series. It might have been dropped during my many rebases. So here he is. The rest is for one part enhancing the battery reporting system (to make it equal to the one in hid-wacom, and even slightly better). The other part is the actual merge of hid-wacom into wacom which gives the same user space API for bluetooth and USB devices, fixes the pad-in-a-separate-input-dev, and fixes the missing tools not supported in the previous implementation of hid-wacom for Intuos 4 BT. Hi Jason, I took your patch through this series, I hope you don't mind, Hi Przemo, Normally, this series contains all the bits of hid-wacom (except the custom LED/OLED API). Please tell me if I am missing anything and if you like the change. Cheers, Benjamin Benjamin Tissoires (9): Input - wacom: put a flag when the led are initialized Input - wacom: enhance Wireless Receiver battery reporting Input - wacom: use a uniq name for the battery device Input - wacom: register an ac power supply for wireless devices Input - wacom: prepare the driver to include BT devices Input - wacom: handle Graphire BT tablets in wacom.ko Input - wacom: handle Intuos 4 BT in wacom.ko Input - wacom: add copyright note and bump version to 2.0 HID: remove hid-wacom Bluetooth driver Jason Gerecke (1): Input - wacom: Support up to 2048 pressure levels with ISDv4 drivers/hid/Kconfig | 10 +- drivers/hid/Makefile| 3 +- drivers/hid/hid-core.c | 2 - drivers/hid/hid-wacom.c | 973 drivers/hid/wacom.h | 11 + drivers/hid/wacom_sys.c | 217 ++- drivers/hid/wacom_wac.c | 195 +- drivers/hid/wacom_wac.h | 10 + 8 files changed, 415 insertions(+), 1006 deletions(-) delete mode 100644 drivers/hid/hid-wacom.c -- 2.0.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 00/10] Input - wacom: conversion to HID driver, series 2
Hi Dmitry, this is the second series I told you about for wacom.ko. This series also have a good number of removed lines of code. \o/ The first patch is Jason's one that I finally decided to take with me. His previous submission still applied correctly even after the moving of the files (git is definitively awesome). The second one is a patch I sent earlier and forgot to include in the v2 of the first series. It might have been dropped during my many rebases. So here he is. The rest is for one part enhancing the battery reporting system (to make it equal to the one in hid-wacom, and even slightly better). The other part is the actual merge of hid-wacom into wacom which gives the same user space API for bluetooth and USB devices, fixes the pad-in-a-separate-input-dev, and fixes the missing tools not supported in the previous implementation of hid-wacom for Intuos 4 BT. Hi Jason, I took your patch through this series, I hope you don't mind, Hi Przemo, Normally, this series contains all the bits of hid-wacom (except the custom LED/OLED API). Please tell me if I am missing anything and if you like the change. Cheers, Benjamin Benjamin Tissoires (9): Input - wacom: put a flag when the led are initialized Input - wacom: enhance Wireless Receiver battery reporting Input - wacom: use a uniq name for the battery device Input - wacom: register an ac power supply for wireless devices Input - wacom: prepare the driver to include BT devices Input - wacom: handle Graphire BT tablets in wacom.ko Input - wacom: handle Intuos 4 BT in wacom.ko Input - wacom: add copyright note and bump version to 2.0 HID: remove hid-wacom Bluetooth driver Jason Gerecke (1): Input - wacom: Support up to 2048 pressure levels with ISDv4 drivers/hid/Kconfig | 10 +- drivers/hid/Makefile| 3 +- drivers/hid/hid-core.c | 2 - drivers/hid/hid-wacom.c | 973 drivers/hid/wacom.h | 11 + drivers/hid/wacom_sys.c | 217 ++- drivers/hid/wacom_wac.c | 195 +- drivers/hid/wacom_wac.h | 10 + 8 files changed, 415 insertions(+), 1006 deletions(-) delete mode 100644 drivers/hid/hid-wacom.c -- 2.0.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
