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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
