digimend-devel Mailing List for DIGImend (Page 13)
Brought to you by:
spb_nick
Menu
▾
▴
digimend-devel — Development matters
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
(27) |
Jul
(54) |
Aug
(54) |
Sep
(13) |
Oct
(20) |
Nov
(7) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(3) |
Feb
(3) |
Mar
(6) |
Apr
(1) |
May
(8) |
Jun
(5) |
Jul
(4) |
Aug
(10) |
Sep
(44) |
Oct
(12) |
Nov
(5) |
Dec
(14) |
| 2014 |
Jan
(16) |
Feb
(3) |
Mar
(3) |
Apr
(5) |
May
(2) |
Jun
(14) |
Jul
(38) |
Aug
(15) |
Sep
(15) |
Oct
(12) |
Nov
(38) |
Dec
(31) |
| 2015 |
Jan
(73) |
Feb
(71) |
Mar
(57) |
Apr
(36) |
May
(33) |
Jun
(20) |
Jul
(4) |
Aug
(5) |
Sep
(1) |
Oct
(11) |
Nov
(2) |
Dec
(6) |
| 2016 |
Jan
(7) |
Feb
(3) |
Mar
(6) |
Apr
(2) |
May
(7) |
Jun
(5) |
Jul
(3) |
Aug
(5) |
Sep
(5) |
Oct
(8) |
Nov
(13) |
Dec
|
|
From: Nikolai K. <sp...@gm...> - 2015-01-26 07:24:11
|
On 01/26/2015 12:36 AM, Mike Sapsard wrote:
> Nick,
>
> hid-rebind modified as requested. The syslog file is attached.
Thank you. So it's not being called at all.
Could you please disconnect the tablet, start this command:
sudo udevadm monitor -p -k -u >udevadm.log
connect the tablet, wait a second, stop the command with Ctrl-C and send me
the resulting udevadm.log file?
Thank you.
Nick
|
|
From: Vince H. <Vi...@Pl...> - 2015-01-26 04:33:49
|
Do you have a list of tablets that work with the wacom driver. I have the kde incident. If you could send the hex ids brand name and model I could add them to the incident. To see if they would add them to the kde tablet setup. ------------ Vince |
|
From: Mike S. <mik...@gm...> - 2015-01-25 22:36:13
|
Nick, hid-rebind modified as requested. The syslog file is attached. Mike On 25/01/15 21:22, Nikolai Kondrashov wrote: > On 01/25/2015 09:12 PM, Mike Sapsard wrote: >> Nick, >> >> I have not update the kernel recently. It is 3.13.0-37-generic. >> >> I have uninstalled and reinstalled the driver using the following >> commands. >> >> sudo make uninstall >> sudo make clean >> sudo make >> sudo make install >> >> The behaviour remains the same with hot plugging. The applications >> 'see' the tablet in preferences, react to the button presses but do >> not draw or select menu items. >> >> The attachment is the Xorg.0.log file, in case that provides any new >> information. > > Thank you. > > Could you please try a little trick: > > Open /sbin/hid-rebind in a text editor as root and replace this line: > > set -e -u > > with this line: > > set -e -u -x > > Then reconnect the tablet and send the /var/log/syslog contents. > > Thank you. > > Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-01-25 21:22:29
|
On 01/25/2015 09:12 PM, Mike Sapsard wrote:
> Nick,
>
> I have not update the kernel recently. It is 3.13.0-37-generic.
>
> I have uninstalled and reinstalled the driver using the following commands.
>
> sudo make uninstall
> sudo make clean
> sudo make
> sudo make install
>
> The behaviour remains the same with hot plugging. The applications 'see' the tablet in preferences, react to the button presses but do not draw or select menu items.
>
> The attachment is the Xorg.0.log file, in case that provides any new information.
Thank you.
Could you please try a little trick:
Open /sbin/hid-rebind in a text editor as root and replace this line:
set -e -u
with this line:
set -e -u -x
Then reconnect the tablet and send the /var/log/syslog contents.
Thank you.
Nick
|
|
From: Nikolai K. <sp...@gm...> - 2015-01-25 21:16:02
|
Hi Mike, On 01/25/2015 10:15 PM, Mike Sapsard wrote: > I may have found an indication of the cause of the problem. I uninstalled and reinstalled the drivers again, and watched the messages. > > The attachment shows a screenshot of the 'make' and 'make install'. In the install there are two 'Can't read private key' statements. > > Searching the net indicates that it is a problem with 'make', but I don't understand enough to correct it. This the kernel module build system trying to sign the modules. It shouldn't affect module loading, unless you explicitly enabled module signature verification, but then you would know. Nick |
|
From: Mike S. <mik...@gm...> - 2015-01-25 20:15:15
|
Nick, I may have found an indication of the cause of the problem. I uninstalled and reinstalled the drivers again, and watched the messages. The attachment shows a screenshot of the 'make' and 'make install'. In the install there are two 'Can't read private key' statements. Searching the net indicates that it is a problem with 'make', but I don't understand enough to correct it. Mike On 25/01/15 13:00, Nikolai Kondrashov wrote: > On 01/25/2015 01:51 PM, Nikolai Kondrashov wrote: >> Hi Mike, >> >> On 01/23/2015 12:23 PM, Mike Sapsard wrote: >>> Attached is the syslog file that shows the hot plug. >>> >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.685421] usb 3-4: >>> new full-speed USB device number 2 using xhci_hcd >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702821] usb 3-4: >>> New USB device found, idVendor=5543, idProduct=0081 >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702829] usb 3-4: >>> New USB device strings: Mfr=5, Product=6, SerialNumber=0 >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702832] usb 3-4: >>> Product: ugee-1000L >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702835] usb 3-4: >>> Manufacturer: UC-LOGIC >>> Jan 23 10:13:35 mike-SATELLITE-P850 mtp-probe: checking bus 3, >>> device 2: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-4" >>> Jan 23 10:13:35 mike-SATELLITE-P850 mtp-probe: bus: 3, device: 2 was >>> not an MTP device >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.765567] hidraw: >>> raw HID events driver (C) Jiri Kosina >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.772197] usbcore: >>> registered new interface driver usbhid >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.772201] usbhid: >>> USB HID core driver >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.790819] input: >>> UC-LOGIC ugee-1000L as >>> /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/input/input15 >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791057] >>> hid-generic 0003:5543:0081.0001: input,hidraw0: USB HID v1.11 Mouse >>> [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-4/input0 >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791238] input: >>> UC-LOGIC ugee-1000L as >>> /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.1/input/input16 >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791421] >>> hid-generic 0003:5543:0081.0002: input,hiddev0,hidraw1: USB HID >>> v1.11 Mouse [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-4/input1 >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791938] input: >>> UC-LOGIC ugee-1000L as >>> /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.2/input/input17 >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.792086] >>> hid-generic 0003:5543:0081.0003: input,hidraw2: USB HID v1.11 >>> Keyboard [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-4/input2 >> >> Right, I see that it is not rebinding to the out-of-tree driver. >> >> I'll try the driver on Linux Mint 17.1 myself today. > > It works for me on a fresh install. Have you, by any chance, upgraded the > kernel recently? If so, you need to reinstall the driver. > > This is an unfortunate limitation for now. > > Nick |
|
From: Mike S. <mik...@gm...> - 2015-01-25 19:12:16
|
Nick, I have not update the kernel recently. It is 3.13.0-37-generic. I have uninstalled and reinstalled the driver using the following commands. sudo make uninstall sudo make clean sudo make sudo make install The behaviour remains the same with hot plugging. The applications 'see' the tablet in preferences, react to the button presses but do not draw or select menu items. The attachment is the Xorg.0.log file, in case that provides any new information. Mike On 25/01/15 13:00, Nikolai Kondrashov wrote: > On 01/25/2015 01:51 PM, Nikolai Kondrashov wrote: >> Hi Mike, >> >> On 01/23/2015 12:23 PM, Mike Sapsard wrote: >>> Attached is the syslog file that shows the hot plug. >>> >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.685421] usb 3-4: >>> new full-speed USB device number 2 using xhci_hcd >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702821] usb 3-4: >>> New USB device found, idVendor=5543, idProduct=0081 >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702829] usb 3-4: >>> New USB device strings: Mfr=5, Product=6, SerialNumber=0 >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702832] usb 3-4: >>> Product: ugee-1000L >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702835] usb 3-4: >>> Manufacturer: UC-LOGIC >>> Jan 23 10:13:35 mike-SATELLITE-P850 mtp-probe: checking bus 3, >>> device 2: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-4" >>> Jan 23 10:13:35 mike-SATELLITE-P850 mtp-probe: bus: 3, device: 2 was >>> not an MTP device >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.765567] hidraw: >>> raw HID events driver (C) Jiri Kosina >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.772197] usbcore: >>> registered new interface driver usbhid >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.772201] usbhid: >>> USB HID core driver >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.790819] input: >>> UC-LOGIC ugee-1000L as >>> /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/input/input15 >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791057] >>> hid-generic 0003:5543:0081.0001: input,hidraw0: USB HID v1.11 Mouse >>> [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-4/input0 >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791238] input: >>> UC-LOGIC ugee-1000L as >>> /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.1/input/input16 >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791421] >>> hid-generic 0003:5543:0081.0002: input,hiddev0,hidraw1: USB HID >>> v1.11 Mouse [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-4/input1 >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791938] input: >>> UC-LOGIC ugee-1000L as >>> /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.2/input/input17 >>> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.792086] >>> hid-generic 0003:5543:0081.0003: input,hidraw2: USB HID v1.11 >>> Keyboard [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-4/input2 >> >> Right, I see that it is not rebinding to the out-of-tree driver. >> >> I'll try the driver on Linux Mint 17.1 myself today. > > It works for me on a fresh install. Have you, by any chance, upgraded the > kernel recently? If so, you need to reinstall the driver. > > This is an unfortunate limitation for now. > > Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-01-25 14:44:34
|
On 01/25/2015 04:41 PM, Nikolai Kondrashov wrote: > So, I think the path to a solution here should be making a separate HID driver > for this tablet and having a new set of report descriptors written, replacing > the original ones. Perhaps with some bit tweaking of the input reports as > well. > > You can take hid-uclogic.c for boilerplate, as the most basic HID driver at > the moment doing similar things. Oh, and doing it within digimend-kernel-drivers package might be easier than on the whole kernel tree. Nick [1] https://github.com/DIGImend/digimend-kernel-drivers |
|
From: Nikolai K. <sp...@gm...> - 2015-01-25 14:41:14
|
Hi Yann,
On 01/20/2015 03:46 PM, Yann Vernier wrote:
> I have a couple of PT-1001 tablets, also known as " Digi Tablet" over USB.
> Mine happen to be branded Leogics, but many other brands occur, including none.
> The USB vendor is 0x099a Zippy Technology Corp.
>
> It presents three interfaces: one keyboard and two pointers. The purpose of
> the second pointer device is somewhat unclear as it does not seem to produce
> events, but its descriptors do describe it as a stylus with only three buttons
> plus presence.
The second pointer interface is probably for a mouse (or "puck" in the old
parlance), which is supported by the hardware, but is not supplied with this
product. OTOH, they support "mouse" mode as is and the tablet working area is
very small, although the hardware might support bigger ones.
> With recent Linux kernels these produce no events and a couple of warnings:
> [ 6719.887522] hid-generic 0003:099A:2620.001C: input,hidraw3: USB HID v1.10 Keyboard [ Digi Tablet] on usb-0000:00:14.0-7/input0
> [ 6719.997108] hid-generic 0003:099A:2620.001D: unknown main item tag 0x0
> [ 6719.997114] hid-generic 0003:099A:2620.001D: unbalanced collection at end of report description
> [ 6719.997121] hid-generic: probe of 0003:099A:2620.001D failed with error -22
>
> I've tracked that problem down; Linux requests precisely the exact buffer and
> transfer size for the report descriptors, and this device has an off by one
> bug where it doesn't send the last byte. In the particular descriptor for the
> events it does send, that last byte is a C0 = End Collection, so the structure
> breaks and Linux ignores that interface (it has three). USB transfer dumps
> show Windows requests 64 bytes more than the descriptor size, which explains
> why it does not trigger this bug.
Wow, that is quite an ugly bug and neat research!
> Possible workarounds include patching in that extra byte or requesting more
> (both tested and work). A proper fix would probably include not trying to
> parse more descriptor data than the device actually returned.
Well, such fix still wouldn't work with devices which would get a more
important part of their report descriptor lost. Then, making the parser handle
all the possible failures it introduces would make it too complicated.
> I do suggest requesting more than the descriptor length by default, since
> this bug may be present in other devices (possibly as a misinterpretation of
> USB's use of a full frame to indicate more data is available). My own test
> was simply to add 1 to rsize and dev_rsize in kmalloc and
> hid_get_class_descriptor calls within drivers/hid/usbhid/hid-core.c, but
> that doesn't check how much was actually received.
This would be one controversial solution. How much more would we need to
request? Would this encourage more sloppy HID descriptors in the future? When
should we stop requesting more and more?
I would say we simply replace the device descriptor with a rewritten
descriptor as is done for many other devices already. See hid-uclogic.c for
example.
> That's not the end of the story, however. Even with proper parsing of the
> descriptors it seems the tablet only has one interface that reports a stylus,
> and it's not the one sending events. This causes the Xorg driver to deduce it
> is a touchpad, not a pen tablet, with all the resulting defects (relative
> mode, ignoring events when the nib isn't pressed). It also reports a rather
> mystifying set of buttons (from xinput list-props, but do come from kernel,
> as confirmed using input-events):
> Button Labels (276): "Button Left" (145), "Button Middle" (146),
> "Button Right" (147), "Button Wheel Up" (148), "Button Wheel Down" (149),
> "Button Horiz Wheel Left" (150), "Button Horiz Wheel Right" (151),
> "Button Side" (265), "Button Extra" (266), "Button Forward" (714),
> "Button Back" (715), "Button Task" (716), "Button Unknown" (264),
> "Button Unknown" (264), "Button Unknown" (264), "Button Unknown" (264)
> The second pointer device reported, which does not produce events, has an
> equally useless button map:
> "Button 0" (630), "Button Unknown" (264), "Button Unknown" (264),
> "Button Wheel Up" (148), "Button Wheel Down" (149)
>
> The actual buttons (nib and two side buttons on the stylus) are those
> reported as Forward, Back and Task. Remapping them with xinput set-button-map
> and setting absolute mode makes it usable but with the serious issue of not
> moving the pointer if the nib isn't pressed (the pressure level works in
> inkscape). I did not find a way to tell Xorg's evdev driver that the device
> is a tablet.
Windows report descriptor parsing works quite differently from Linux and such
mapping issues happen often.
We can avoid this problem altogether by simply using appropriate field
usages in the rewritten report descriptor.
> Among the firmware controlled soft buttons (tappable with the stylus) on
> the tablet itself is a mouse/stylus switch control. The other side fields
> produce other events, mostly keyboard combinations (common zoom hotkeys,
> save, open, copy, paste etc) and scroll events. Using this toggle to set
> mouse mode causes the first group of buttons to be used, so does map to
> mouse buttons by default, but the pointer motion is ignored by X (since
> it does not report pressure, this might be an artifact of its touchpad
> misinterpretation). The keyboard events are sent on interface 0.
>
> So, on interface 1, we have a bunch of possible reports:
> 1 5 button relative XY, sent in mouse mode (boot protocol compatible?)
> 2 scroll wheel? duplicated in descriptor. usages Wheel and AC Pan
> 3 Unknown use, looks like keyboard reports
> 5 multimedia buttons
> 9 tablet mode stylus events
> As it happens, it looks like it sticks to report 9 and keyboard events
> on interface 0, switching to report 1 in mouse mode.
Wow! This is the first tablet I see that is trying to actually convert
various working area events into something else in *hardware*, i.e. on the
device side. All others do this in the driver.
> And the kernel has dutifully collected all those possible buttons in one
> device, placing the tablet ones at number 10-12. The hint that this is
> a pen tablet is in interface 2, which maps to another device. It could
> be that Windows associates the two, maybe by bInterfaceProtocol=3?
>
> The failing heuristic in Xorg's evdev driver is:
> if ((libevdev_has_event_code(pEvdev->dev, EV_ABS, ABS_X) &&
> libevdev_has_event_code(pEvdev->dev, EV_ABS, ABS_Y))) {
> xf86IDrvMsg(pInfo, X_PROBED, "Found x and y absolute axes\n");
> if (libevdev_has_event_code(pEvdev->dev, EV_KEY, BTN_TOOL_PEN) ||
> libevdev_has_event_code(pEvdev->dev, EV_KEY, BTN_STYLUS) ||
> libevdev_has_event_code(pEvdev->dev, EV_KEY, BTN_STYLUS2))
> {
> xf86IDrvMsg(pInfo, X_PROBED, "Found absolute tablet.\n");
> pEvdev->flags |= EVDEV_TABLET;
> if (!pEvdev->num_buttons)
> {
> pEvdev->num_buttons = 7; /* LMR + scroll wheels */
> pEvdev->flags |= EVDEV_BUTTON_EVENTS;
> }
> } else if (libevdev_has_event_code(pEvdev->dev, EV_ABS, ABS_PRESSURE) ||
> libevdev_has_event_code(pEvdev->dev, EV_KEY, BTN_TOUCH)) {
> if (has_lmr || libevdev_has_event_code(pEvdev->dev, EV_KEY, BTN_TOOL_FINGER)) {
> xf86IDrvMsg(pInfo, X_PROBED, "Found absolute touchpad.\n");
> pEvdev->flags |= EVDEV_TOUCHPAD;
> } else {
> xf86IDrvMsg(pInfo, X_PROBED, "Found absolute touchscreen\n");
> pEvdev->flags |= EVDEV_TOUCHSCREEN;
> pEvdev->flags |= EVDEV_BUTTON_EVENTS;
> }
> } else if (!(libevdev_has_event_code(pEvdev->dev, EV_REL, REL_X) &&
> libevdev_has_event_code(pEvdev->dev, EV_REL, REL_Y)) && has_lmr) {
> /* some touchscreens use BTN_LEFT rather than BTN_TOUCH */
> xf86IDrvMsg(pInfo, X_PROBED, "Found absolute touchscreen\n");
> pEvdev->flags |= EVDEV_TOUCHSCREEN;
> pEvdev->flags |= EVDEV_BUTTON_EVENTS;
> }
> } else {
> #ifdef MULTITOUCH
> if (!libevdev_has_event_code(pEvdev->dev, EV_ABS, ABS_MT_POSITION_X) ||
> !libevdev_has_event_code(pEvdev->dev, EV_ABS, ABS_MT_POSITION_Y))
> #endif
> EvdevForceXY(pInfo, Absolute);
> }
>
> For interface 1 this code finds absolute axis, including pressure, but no
> button marked stylus (it is marked as mouse button 1, but mislabeled as Back
> by the kernel somehow), and so it decides on a touchpad. This single error
> causes it to set relative mode and ignore any motion without pressure.
>
>
> So, opinions? How should these flaws be patched?
This X.org heuristic is pretty hairy, yes, but we can still cater to it by
using appropriate report descriptor(s).
So, I think the path to a solution here should be making a separate HID driver
for this tablet and having a new set of report descriptors written, replacing
the original ones. Perhaps with some bit tweaking of the input reports as
well.
You can take hid-uclogic.c for boilerplate, as the most basic HID driver at
the moment doing similar things. If you know how report descriptors work you
can try making one yourself. I can suggest using my hidrd-convert [1] tool for
authoring, although there are a few others. You can find some examples of
rewritten descriptor XML sources in our tablets repo [2] - search for
"fixed*.xml".
Otherwise you can map the bits of all the reports on all the interfaces and I
can try writing them for you, but doing it yourself might be faster and more
fun :)
Thank you for thorough research and description of the problem!
Nick
[1] https://github.com/DIGImend/hidrd
[2] https://github.com/DIGImend/tablets
|
|
From: Nikolai K. <sp...@gm...> - 2015-01-25 14:05:34
|
Hello Masaru, On 01/22/2015 01:40 PM, Masaru Hirano wrote: > Hello Nick > > Thanks for waiting for my reply. Congrats on getting well! > Tests are over. > I have atatced the result. > > M1000L,M708,M860 are work fine. > Thanks. Good. Could you please explain your testing method? It is important to be sure the driver really works. Have you tested on a fresh Linux install? Which distro? Could you please send the output of "evtest" command for one of the working tablets when you do the "pen coordinates sample" as shown here: https://www.youtube.com/watch?v=ysYk8KLY98U > Other products will be collected the data. > > If you have information how to modify source code, > please let me know. Sure. Thank you. Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-01-25 13:41:49
|
Hi Milan, On 01/18/2015 08:47 PM, Milan Plžík wrote: > thank you for your comments. I added the missing <pop/> element. With the > 'digitizer eraser' button, I hoped to temporarily switch a tool to eraser, > but as you noted, that did not work. I reverted it to AC Delete, which is > probably the closest description I could find in the HID Usage Tables > document. Attached is both the kernel patch to current master and the fixed > descriptor XML. Sorry for another delay. I think it is fine. Even though the button functions don't match the pictures beside them exactly, it is more important for them to be actually useful to users. With regards to actually contributing this, I think with this patch quality you can go directly to the kernel maintainers. Send this patch (with "git send-email", if you can) to Jiri Kosina <jk...@su...> and CC it to lin...@vg.... Please also CC dig...@li... and me and I'll put my Reviewed-by on it, FWIW. Thanks a lot for your work! Another good thing to do would be contributing this to digimend-kernel-drivers [1] as well, so users of older kernel versions can use it sooner/more easily. Regarding the report descriptor XML, I'd like to note that you can use the "PUSH" (uppercase) element instead of the "push"/"pop" element pair to make it standout more. But if you don't plan to write any more report descriptor in hidrd XML, it shouldn't matter to you :) Regarding the buttons, I've experimented a little with making the hid-huion.c driver report generic button presses [2], which can then be remapped by xf86-input-wacom, but hasn't arrived to a good compatible solution yet. Perhaps you can take some ideas from there to improve your tablet button mapping. Nick [1] https://github.com/DIGImend/digimend-kernel-drivers [2] https://github.com/DIGImend/digimend-kernel-drivers/tree/huion-abstract-keyboard |
|
From: Nikolai K. <sp...@gm...> - 2015-01-25 13:00:17
|
On 01/25/2015 01:51 PM, Nikolai Kondrashov wrote: > Hi Mike, > > On 01/23/2015 12:23 PM, Mike Sapsard wrote: >> Attached is the syslog file that shows the hot plug. >> >> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.685421] usb 3-4: new full-speed USB device number 2 using xhci_hcd >> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702821] usb 3-4: New USB device found, idVendor=5543, idProduct=0081 >> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702829] usb 3-4: New USB device strings: Mfr=5, Product=6, SerialNumber=0 >> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702832] usb 3-4: Product: ugee-1000L >> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702835] usb 3-4: Manufacturer: UC-LOGIC >> Jan 23 10:13:35 mike-SATELLITE-P850 mtp-probe: checking bus 3, device 2: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-4" >> Jan 23 10:13:35 mike-SATELLITE-P850 mtp-probe: bus: 3, device: 2 was not an MTP device >> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.765567] hidraw: raw HID events driver (C) Jiri Kosina >> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.772197] usbcore: registered new interface driver usbhid >> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.772201] usbhid: USB HID core driver >> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.790819] input: UC-LOGIC ugee-1000L as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/input/input15 >> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791057] hid-generic 0003:5543:0081.0001: input,hidraw0: USB HID v1.11 Mouse [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-4/input0 >> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791238] input: UC-LOGIC ugee-1000L as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.1/input/input16 >> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791421] hid-generic 0003:5543:0081.0002: input,hiddev0,hidraw1: USB HID v1.11 Mouse [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-4/input1 >> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791938] input: UC-LOGIC ugee-1000L as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.2/input/input17 >> Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.792086] hid-generic 0003:5543:0081.0003: input,hidraw2: USB HID v1.11 Keyboard [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-4/input2 > > Right, I see that it is not rebinding to the out-of-tree driver. > > I'll try the driver on Linux Mint 17.1 myself today. It works for me on a fresh install. Have you, by any chance, upgraded the kernel recently? If so, you need to reinstall the driver. This is an unfortunate limitation for now. Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-01-25 11:51:44
|
Hi Mike, On 01/23/2015 12:23 PM, Mike Sapsard wrote: > Attached is the syslog file that shows the hot plug. > > Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.685421] usb 3-4: new full-speed USB device number 2 using xhci_hcd > Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702821] usb 3-4: New USB device found, idVendor=5543, idProduct=0081 > Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702829] usb 3-4: New USB device strings: Mfr=5, Product=6, SerialNumber=0 > Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702832] usb 3-4: Product: ugee-1000L > Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.702835] usb 3-4: Manufacturer: UC-LOGIC > Jan 23 10:13:35 mike-SATELLITE-P850 mtp-probe: checking bus 3, device 2: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-4" > Jan 23 10:13:35 mike-SATELLITE-P850 mtp-probe: bus: 3, device: 2 was not an MTP device > Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.765567] hidraw: raw HID events driver (C) Jiri Kosina > Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.772197] usbcore: registered new interface driver usbhid > Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.772201] usbhid: USB HID core driver > Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.790819] input: UC-LOGIC ugee-1000L as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/input/input15 > Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791057] hid-generic 0003:5543:0081.0001: input,hidraw0: USB HID v1.11 Mouse [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-4/input0 > Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791238] input: UC-LOGIC ugee-1000L as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.1/input/input16 > Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791421] hid-generic 0003:5543:0081.0002: input,hiddev0,hidraw1: USB HID v1.11 Mouse [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-4/input1 > Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.791938] input: UC-LOGIC ugee-1000L as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.2/input/input17 > Jan 23 10:13:35 mike-SATELLITE-P850 kernel: [ 168.792086] hid-generic 0003:5543:0081.0003: input,hidraw2: USB HID v1.11 Keyboard [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-4/input2 Right, I see that it is not rebinding to the out-of-tree driver. I'll try the driver on Linux Mint 17.1 myself today. Nick |
|
From: Mike S. <mik...@gm...> - 2015-01-23 10:24:02
|
Nick, Attached is the syslog file that shows the hot plug. Mike On 21/01/15 20:23, Nikolai Kondrashov wrote: > On 01/21/2015 12:37 PM, Mike Sapsard wrote: >> I have now found that for the tablet to be recognised, it should be >> plugged >> in before starting the PC. > > That's interesting. It should work on hot plug. > > Could you please boot your PC up without it plugged in, then plug it > in and > send the resulting /var/log/syslog file? > >> I also found that the left hand F5 and F6 keys do register + and - in >> the >> Gimp Configure Input Devices screen. However, the actual usage is as I >> reported before. > > Well, we'll have to live with that for now. > > Nick |
|
From: Masaru H. <mh...@ne...> - 2015-01-22 11:40:52
|
Hello Nick Thanks for waiting for my reply. Tests are over. I have atatced the result. M1000L,M708,M860 are work fine. Thanks. Other products will be collected the data. If you have information how to modify source code, please let me know. best regards, Masaru Hirano Neoblast Inc. On 2015年01月01日 01:19, Nikolai Kondrashov wrote: > Hi Masaru, > > On 12/30/2014 12:44 PM, Masaru Hirano wrote: >> Thanks for your new driver. >> Ugee-1000-L works fine. > > Good. How did you verify it exactly? > Could you please provide evtest dumps of the pen coords test? > Did you have any special X.org configuration, like using the WizardPen > driver? > >> According to change of this case. >> I could found 4 changes by sources. >> But I can not adopt for other model. >> Please teach me how to fit for other models. >> All the product uses UC-LOGIC > > I assumed that all your models have the UC-Logic vendor ID (0x5543) and > either > the 0x45 or 0x81 product ID. If that's so, the driver should attempt to > handle > all of them and no further code change should be necessary. > > Do you have tablets with other VID:PID pairs? > >> So I have tried same way. >> Ugee-M708 model >> But this model does not work correctry. >> Please teach me how to add other model. >> M708 Model diagnostic files are attathched. >> This case strange output >> $xinput list > xinputlist.txt >> UC-LOIC is strange. > > "UC-LOIC" is a typo on behalf of the manufacturer. It's what they've put > into > their device and string descriptors themselves. > >> $ xinput list >> ⎡ Virtual core pointer id=2 [master pointer >> (2)] >> ⎜ ↳ UC-LOIC TABLET 1060 id=10 [slave >> pointer (2)] >> ⎜ ↳ UC-LOIC TABLET 1060 id=11 [slave >> pointer (2)] >> ⎜ ↳ UC-LOIC TABLET 1060 id=12 [slave >> pointer (2)] >> >> I have tried M708 model diagnostic. > > Were these diagnostic files collected with the driver installed? The tablet > should work fine as the coordinate range seems to be full and correct. > Do you, > by any chance, still use the WizardPen driver? Could you please provide > evtest > dumps of the pen coords test for this tablet as well? > > Nick > > On 12/30/2014 12:44 PM, Masaru Hirano wrote: >> Hello Nick >> >> Thanks for your new driver. >> Ugee-1000-L works fine. >> >> According to change of this case. >> I could found 4 changes by sources. >> But I can not adopt for other model. >> Please teach me how to fit for other models. >> All the product uses UC-LOGIC >> >> 1.hid-huion.c >> these two codes are added. >> >> line228: >> case USB_DEVICE_ID_UGEE_TABLET_81: >> line229: >> case USB_DEVICE_ID_UGEE_TABLET_45: >> >> 2.hid-hion.c >> these two codes are added. >> line275: >> { HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC, USB_DEVICE_ID_UGEE_TABLET_81) }, >> >> line276: >> { HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC, USB_DEVICE_ID_UGEE_TABLET_45) }, >> >> 3.hid-ids.h >> these two codes are added. >> line:22 >> #define USB_DEVICE_ID_UGEE_TABLET_81 0x0081 >> line:22 >> #define USB_DEVICE_ID_UGEE_TABLET_45 0x0045 >> >> So I have tried same way. >> Ugee-M708 model >> But this model does not work correctry. >> Please teach me how to add other model. >> M708 Model diagnostic files are attathched. >> This case strange output >> $xinput list > xinputlist.txt >> UC-LOIC is strange. >> >> $ xinput list >> ⎡ Virtual core pointer id=2 [master pointer >> (2)] >> ⎜ ↳ UC-LOIC TABLET 1060 id=10 [slave >> pointer (2)] >> ⎜ ↳ UC-LOIC TABLET 1060 id=11 [slave >> pointer (2)] >> ⎜ ↳ UC-LOIC TABLET 1060 id=12 [slave >> pointer (2)] >> >> I have tried M708 model diagnostic. >> >> According to these way >> http://digimend.github.io/support/howto/trbl/diagnostics/ >> >> >> 1.Identify original model >> $ lsusb >> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 007 Device 002: ID 5543:0081 UC-Logic Technology Corp. >> Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 006 Device 003: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse >> Bus 006 Device 002: ID 0518:0001 EzKEY Corp. USB to PS2 Adaptor v1.09 >> Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> >> VID=5543 >> PID=0081 >> >> $ T=5543:0081 >> >> 2.Retrieve USB descriptors >> 1)sudo lsusb -v -d $T > descriptors.txt >> Bus 007 Device 002: ID 5543:0081 UC-Logic Technology Corp. >> Device Descriptor: >> bLength 18 >> bDescriptorType 1 >> bcdUSB 1.10 >> bDeviceClass 0 (Defined at Interface level) >> bDeviceSubClass 0 >> bDeviceProtocol 0 >> bMaxPacketSize0 64 >> idVendor 0x5543 UC-Logic Technology Corp. >> idProduct 0x0081 >> bcdDevice 0.00 >> iManufacturer 5 UC-LOIC >> iProduct 6 TABLET 1060 >> iSerial 0 >> bNumConfigurations 1 >> ^C >> >> 2) sudo usbhid-dump -ed -m $T > hid_report_descriptors.txt >> Bus 007 Device 002: ID 5543:0081 UC-Logic Technology Corp. >> Device Descriptor: >> bLength 18 >> bDescriptorType 1 >> bcdUSB 1.10 >> bDeviceClass 0 (Defined at Interface level) >> bDeviceSubClass 0 >> bDeviceProtocol 0 >> bMaxPacketSize0 64 >> idVendor 0x5543 UC-Logic Technology Corp. >> idProduct 0x0081 >> bcdDevice 0.00 >> iManufacturer 5 UC-LOIC >> iProduct 6 TABLET 1060 >> iSerial 0 >> bNumConfigurations 1 >> Configuration Descriptor: >> ^C >> >> >> 3.Collect raw input samples >> sudo usbhid-dump -es -m $T | tee frame_wheel_srolling.txt >> 007:002:000:STREAM 1418797530.559580 >> 07 80 84 01 75 01 00 00 >> >> 007:002:000:STREAM 1418797530.565550 >> 07 80 8B 01 6F 01 00 00 >> >> 007:002:000:STREAM 1418797530.573564 >> 07 80 94 01 68 01 00 00 >> >> 007:002:000:STREAM 1418797530.579546 >> 07 81 A0 01 5F 01 89 00 >> ^C >> >> 4.PEN >> $ sudo usbhid-dump -es -m $T | tee pen_coords.txt >> >> 4-1)Pen-Coordinate >> 07 80 82 55 F7 5A 00 00 >> >> 007:002:000:STREAM 1418797673.689610 >> 07 80 89 55 E0 5A 00 00 >> >> 007:002:000:STREAM 1418797673.695597 >> 07 80 91 55 C7 5A 00 00 >> >> 007:002:000:STREAM 1418797673.699593 >> 07 80 98 55 AD 5A 00 00 >> >> 007:002:000:STREAM 1418797673.705596 >> 07 80 9E 55 93 5A 00 00 >> ^C >> >> 4-2)Pen-Tiltangle >> $ sudo usbhid-dump -es -m $T | tee pen_tilt.txt >> Not Supported and skip >> >> >> 4-3)Pen-Pressure >> sudo usbhid-dump -es -m $T | tee pen_pressure.txt >> >> 007:002:000:STREAM 1418797836.355686 >> 07 80 2A 56 48 2D 00 00 >> >> 007:002:000:STREAM 1418797836.477668 >> 07 80 41 56 48 2D 00 00 >> >> 007:002:000:STREAM 1418797836.509667 >> 07 80 58 56 48 2D 00 00 >> >> 007:002:000:STREAM 1418797836.535662 >> 07 80 6B 56 48 2D 00 00 >> ^C >> >> 4-4)Pen-Buttons >> sudo usbhid-dump -es -m $T | tee pen_buttons.txt >> >> 007:002:000:STREAM 1418797957.023720 >> 07 80 9D 3C 37 2B 00 00 >> >> 007:002:000:STREAM 1418797957.169706 >> 07 80 BD 3C 37 2B 00 00 >> >> 007:002:000:STREAM 1418797957.547704 >> 07 80 BD 3C 56 2B 00 00 >> >> 007:002:000:STREAM 1418797957.831697 >> 07 80 DC 3C 56 2B 00 00 >> >> 007:002:000:STREAM 1418797957.855690 >> 07 80 FC 3C 56 2B 00 00 >> >> 007:002:000:STREAM 1418797957.871695 >> 07 80 16 3D 56 2B 00 00 >> >> 007:002:000:STREAM 1418797957.913699 >> 07 80 2E 3D 56 2B 00 00 >> >> >> 5 Frame Controls >> 5-1)Frame Controls Dials >> sudo usbhid-dump -es -m $T | tee frame_dials.txt >> >> Not Supported and skip >> >> 5-1)Frame Controls Buttons >> $ sudo usbhid-dump -es -m $T | tee frame_buttons.txt >> >> >> 007:002:002:STREAM 1418798804.272982 >> 03 04 3D 00 00 00 00 00 >> >> 007:002:002:STREAM 1418798804.792976 >> 03 00 00 00 00 00 00 00 >> >> 007:002:002:STREAM 1418798806.040974 >> 03 01 16 00 00 00 00 00 >> >> 007:002:002:STREAM 1418798806.496976 >> 03 00 00 00 00 00 00 00 >> >> 007:002:002:STREAM 1418798807.552979 >> 03 02 56 00 00 00 00 00 >> ^C >> >> >> 6.Mouse >> 6-1)Mouse-Coordinates >> $ sudo usbhid-dump -es -m $T | tee mouse_coords.txt >> Not Supported and skip >> >> 6-2)Mouse-Buttons >> $ sudo usbhid-dump -es -m $T | tee mouse_buttons.txt >> Not Supported and skip >> >> >> 6-3)Mouse-Wheel >> $ sudo usbhid-dump -es -m $T | tee mouse_wheel.txt >> Not Supported and skip >> >> 7.huion-probe >> 7-1)Identify original model >> $ lsusb > identmodel.txt >> Bus 007 Device 002: ID 5543:0081 UC-Logic Technology Corp. >> bus=7 >> device=2 >> >> 7-2)huion-probe >> $ sudo huion-probe 7 2 > ~/huionprobe.txt >> >> M 55 00 43 00 2D 00 4C 00 4F 00 49 00 43 00 00 00 >> P 54 00 41 00 42 00 4C 00 45 00 54 00 20 00 31 00 30 00 36 00 30 00 >> S 64 0E 03 40 9C C0 5D 03 00 FF 07 A0 0F 08 00 >> S 65 04 03 20 A0 >> S 6E 04 03 30 00 >> S 79 28 03 44 00 46 00 53 00 2D 00 55 00 49 00 20 00 46 00 34 00 30 00 >> 31 00 2D 00 32 00 30 00 31 00 31 00 31 00 30 00 32 00 >> S 7A 08 03 01 08 00 00 00 00 >> >> 7-2)huion-decode >> $ sudo huion-probe 6 3 | huion-decode > ~/huiondecode.txt >> Manufacturer: UC-LOIC? >> Product: TABLET 1060 >> Max X: 40000 >> Max Y: 24000 >> Max pressure: 2047 >> Resolution: 4000 >> Internal model: DFS-UI F401-2011102 >> >> >> 7-2)Calculation >> Active Area 10"x6" >> MaxX / Width = MaxY / Height = Resolution >> >> *40000/Width =4000 >> hence Width=10 >> >> *24000/Height=4000 >> hence Height=6 >> >> Best regards, >> Masaru Hirano >> Neoblast Inc. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 2014年12月15日 02:00, Nikolai Kondrashov wrote: >>> Hi Masaru, >>> >>> On 11/06/2014 07:30 AM, Masaru Hirano wrote: >>>> Hello Nick >>>> >>>> Thanks for your support. >>>> We are Ugee distributer in japan. >>>> Please let us know how to make driver. >>>> >>>> We would like to build ugee tablet driver. >>>> VID=5543 >>>> PID=0081 >>>> These are all fine. >>>> VID=5543 >>>> PID=0045 >>>> These are not work fine. >>>> Calibration does not been succeed. >>> >>> I've made a very simple change to the digimend-kernel-drivers package, >>> which >>> has a slight possibility of making them work. I've simply added both >>> of the >>> product IDs you sent to the list of devices supported by the hid-huion >>> driver, >>> so it would treat them exactly as Huion tablets. >>> >>> The change is available in the "ugee" branch on GitHub, which you can >>> download >>> here: >>> https://github.com/DIGImend/digimend-kernel-drivers/archive/ugee.zip >>> >>> Please try building, installing and using the driver with your >>> tablets. We >>> might just be lucky and they might work. >>> >>> Nick >>> >>> On 11/06/2014 07:30 AM, Masaru Hirano wrote: >>>> Hello Nick >>>> >>>> Thanks for your support. >>>> We are Ugee distributer in japan. >>>> Please let us know how to make driver. >>>> >>>> We would like to build ugee tablet driver. >>>> VID=5543 >>>> PID=0081 >>>> These are all fine. >>>> VID=5543 >>>> PID=0045 >>>> These are not work fine. >>>> Calibration does not been succeed. >>>> >>>> If you give me some procedure and tools for making tablet and tablet >>>> monitor driver. >>>> I would like to make. >>>> Under ubuntu studio 14.04 >>>> >>>> File 1: >>>> VID=5543 >>>> PID=0081 >>>> are work fine. >>>> >>>> File 2: >>>> We would like to build for them. >>>> >>>> We are small company of system integrator for creative buginners. >>>> So we need to provide no wacom tablet and ubuntu-studio 14.04 for >>>> cost effective in Japan. >>>> >>>> Ofcource when we made new driver, we will share for everyone. >>>> >>>> Best regards, >>>> Masaru Hirano >>>> Neoblast Inc. >>>> >>>> On 2014年11月05日 18:24, Nikolai Kondrashov wrote: >>>>> On 11/05/2014 11:22 AM, Nikolai Kondrashov wrote: >>>>>> We would appreciate it, if you could provide us with a list of Ugee >>>>>> tablets >>>>>> which you found working with our tablets >>>>> >>>>> I meant "our drivers", of course. >>>>> >>>>> Nick >>>>> >>>>> On 11/05/2014 11:22 AM, Nikolai Kondrashov wrote: >>>>>> Hello Masaru, >>>>>> >>>>>> I'm very glad to hear that another tablet distributor is choosing to >>>>>> contribute their effort to making Linux drivers for their tablets. >>>>>> >>>>>> This year Yiynova helped with drivers for their tablets as well, and >>>>>> now have >>>>>> a bunch of models supported. >>>>>> >>>>>> We would appreciate it, if you could provide us with a list of Ugee >>>>>> tablets >>>>>> which you found working with our tablets, along with their USB >>>>>> VID:PID >>>>>> pairs, >>>>>> so we can add them to the list and advertise their support. >>>>>> >>>>>> Regarding the so far unsupported tablets, I would also like to know >>>>>> their >>>>>> names and VID:PID pairs, along with their parameters (if those are >>>>>> unavailable >>>>>> on the web). I would also like to know which hardware they're based >>>>>> on, if >>>>>> possible. Is it UC-Logic, Waltop, anything else? >>>>>> >>>>>> This would get us started. >>>>>> >>>>>> Thank you. >>>>>> >>>>>> Sincerely, >>>>>> Nick >>>>>> >>>>>> On 11/05/2014 03:42 AM, Masaru Hirano wrote: >>>>>>> Hello developper >>>>>>> >>>>>>> We are neoblast inc japan. >>>>>>> We are one of Ugee Distributer. >>>>>>> >>>>>>> There are few driver for ugee. >>>>>>> Most of product work by digemend kernel driver. >>>>>>> But some product (tablet monitor, sketch=pad) do not work. >>>>>>> http://ugee.net/index.asp >>>>>>> >>>>>>> We use ubuntu-studio 14.04. >>>>>>> >>>>>>> Digemend kernel driver are not enough for us. >>>>>>> There are no friver for tablet monitor for ubuntu 14.04. >>>>>>> >>>>>>> We would like to build by ourseleves. >>>>>>> Please let us know how to make kernel driver. >>>>>>> >>>>>>> best regards, >>>>>>> Masaru Hirano >>>>>>> neoblast inc. >>>>> >>>>> >>>>> >>> >>> >>> >> > > > -- ========================================= Masaru Hirano Neoblast Inc. Tokiwadai1-67-5-704, Itabashi-ku, Tokyo, Japan ZIP:174-0071 E-Mail:mh...@ne... Tel:+81-3-4570-7345 Mob:+81-70-6575-1732 Fax:+81-20-4623-9249 ========================================= |
|
From: Nikolai K. <sp...@gm...> - 2015-01-21 20:23:31
|
On 01/21/2015 12:37 PM, Mike Sapsard wrote: > I have now found that for the tablet to be recognised, it should be plugged > in before starting the PC. That's interesting. It should work on hot plug. Could you please boot your PC up without it plugged in, then plug it in and send the resulting /var/log/syslog file? > I also found that the left hand F5 and F6 keys do register + and - in the > Gimp Configure Input Devices screen. However, the actual usage is as I > reported before. Well, we'll have to live with that for now. Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-01-21 20:22:09
|
Hi Mike, Please keep the maillist in the CC by using "Reply To All" to answer. It's better when others can see our progress. On 01/20/2015 02:52 PM, Mike Sapsard wrote: > Thank you for the test drivers. I have briefly tested the drivers with Gimp, > MyPaint and Inkscape, and they seem to be good. Great! > The soft buttons do not work - as I expected. However, they simply do not > exist. The top of the tablet coincides with the top of the screen, and the > screen menus work well. The functions printed on the tablet are Windows > centric, and would not be used by me, even if they were Linux centric. Yes, we don't bother with implementing them as they're mostly are marketing feature and are of little use. > The buttons on the left work correctly, except for the F5 and F6 Zoom In and > Out buttons, which never worked. This may irritate you, but is not of major > importance. Details below. > > Gimp: > + and - keys should zoom in and out. > Selecting Zoom In and Out from the screen menu works correctly with the tablet. > Strangely, <Shift>+ and - work correctly on my keyboard. I reset all keys to > the default mapping, but nothing changed. > > MyPaint: > + and - keys should zoom in and out. > <Shift>+ also works, but <Shift>- does not. > Selecting Zoom In and Out from the menu is via 'Adjust View' and works > correctly with the tablet. > > Inkscape: > + and - keys and <Shift>+ and <Shift>- should zoom in and out. > They all work except via the two left hand keys on the tablet. > > The F7 "Save" and F8 "Close" (Alt-F4) buttons worked before I received the > driver from you, and still work correctly. > > I attach a new copy of frame_buttons.txt showing the output when buttons F5 > - "Zoom In" and F6 - "Zoom Out" are pressed. All the generic tablets report Windows application-oriented shortcuts which sometimes coincide with Linux ones. I used to do some report descriptor tricks to remap them, but it's a bit too much work for just having another set of fixed shortcuts. There is some work done to make Huion (and some UC-Logic) tablets report generic buttons for these (Thanks, Vince!), which can then be remapped by the Wacom X.org driver, but it's still raw. Meanwhile these shortcuts will have to do. > I also attach a copy of my email correspondence with Ugee, which may interest you. Ah, that's interesting. Perhaps I'll try contacting them as well. We also had a small distributor(?) from Japan contact us WRT the drivers. You can find that in the maillist archives. > If there are any other tests you would like me to run, please ask. Thank you. I'll likely need some tests done in the future. > I really appreciate your work on this. You're welcome :) In our turn, we always appreciate some help with the project: http://digimend.github.io/#how-to-help Nick |
|
From: Yann V. <yan...@or...> - 2015-01-20 14:08:59
|
I have a couple of PT-1001 tablets, also known as " Digi Tablet" over USB.
Mine happen to be branded Leogics, but many other brands occur, including none.
The USB vendor is 0x099a Zippy Technology Corp.
It presents three interfaces: one keyboard and two pointers. The purpose of
the second pointer device is somewhat unclear as it does not seem to produce
events, but its descriptors do describe it as a stylus with only three buttons
plus presence.
With recent Linux kernels these produce no events and a couple of warnings:
[ 6719.887522] hid-generic 0003:099A:2620.001C: input,hidraw3: USB HID v1.10 Keyboard [ Digi Tablet] on usb-0000:00:14.0-7/input0
[ 6719.997108] hid-generic 0003:099A:2620.001D: unknown main item tag 0x0
[ 6719.997114] hid-generic 0003:099A:2620.001D: unbalanced collection at end of report description
[ 6719.997121] hid-generic: probe of 0003:099A:2620.001D failed with error -22
I've tracked that problem down; Linux requests precisely the exact buffer and
transfer size for the report descriptors, and this device has an off by one
bug where it doesn't send the last byte. In the particular descriptor for the
events it does send, that last byte is a C0 = End Collection, so the structure
breaks and Linux ignores that interface (it has three). USB transfer dumps
show Windows requests 64 bytes more than the descriptor size, which explains
why it does not trigger this bug.
Possible workarounds include patching in that extra byte or requesting more
(both tested and work). A proper fix would probably include not trying to
parse more descriptor data than the device actually returned. I do suggest
requesting more than the descriptor length by default, since this bug may
be present in other devices (possibly as a misinterpretation of USB's use
of a full frame to indicate more data is available). My own test was simply
to add 1 to rsize and dev_rsize in kmalloc and hid_get_class_descriptor
calls within drivers/hid/usbhid/hid-core.c, but that doesn't check how much
was actually received.
That's not the end of the story, however. Even with proper parsing of the
descriptors it seems the tablet only has one interface that reports a stylus,
and it's not the one sending events. This causes the Xorg driver to deduce it
is a touchpad, not a pen tablet, with all the resulting defects (relative
mode, ignoring events when the nib isn't pressed). It also reports a rather
mystifying set of buttons (from xinput list-props, but do come from kernel,
as confirmed using input-events):
Button Labels (276): "Button Left" (145), "Button Middle" (146),
"Button Right" (147), "Button Wheel Up" (148), "Button Wheel Down" (149),
"Button Horiz Wheel Left" (150), "Button Horiz Wheel Right" (151),
"Button Side" (265), "Button Extra" (266), "Button Forward" (714),
"Button Back" (715), "Button Task" (716), "Button Unknown" (264),
"Button Unknown" (264), "Button Unknown" (264), "Button Unknown" (264)
The second pointer device reported, which does not produce events, has an
equally useless button map:
"Button 0" (630), "Button Unknown" (264), "Button Unknown" (264),
"Button Wheel Up" (148), "Button Wheel Down" (149)
The actual buttons (nib and two side buttons on the stylus) are those
reported as Forward, Back and Task. Remapping them with xinput set-button-map
and setting absolute mode makes it usable but with the serious issue of not
moving the pointer if the nib isn't pressed (the pressure level works in
inkscape). I did not find a way to tell Xorg's evdev driver that the device
is a tablet.
Among the firmware controlled soft buttons (tappable with the stylus) on
the tablet itself is a mouse/stylus switch control. The other side fields
produce other events, mostly keyboard combinations (common zoom hotkeys,
save, open, copy, paste etc) and scroll events. Using this toggle to set
mouse mode causes the first group of buttons to be used, so does map to
mouse buttons by default, but the pointer motion is ignored by X (since
it does not report pressure, this might be an artifact of its touchpad
misinterpretation). The keyboard events are sent on interface 0.
So, on interface 1, we have a bunch of possible reports:
1 5 button relative XY, sent in mouse mode (boot protocol compatible?)
2 scroll wheel? duplicated in descriptor. usages Wheel and AC Pan
3 Unknown use, looks like keyboard reports
5 multimedia buttons
9 tablet mode stylus events
As it happens, it looks like it sticks to report 9 and keyboard events
on interface 0, switching to report 1 in mouse mode.
And the kernel has dutifully collected all those possible buttons in one
device, placing the tablet ones at number 10-12. The hint that this is
a pen tablet is in interface 2, which maps to another device. It could
be that Windows associates the two, maybe by bInterfaceProtocol=3?
The failing heuristic in Xorg's evdev driver is:
if ((libevdev_has_event_code(pEvdev->dev, EV_ABS, ABS_X) &&
libevdev_has_event_code(pEvdev->dev, EV_ABS, ABS_Y))) {
xf86IDrvMsg(pInfo, X_PROBED, "Found x and y absolute axes\n");
if (libevdev_has_event_code(pEvdev->dev, EV_KEY, BTN_TOOL_PEN) ||
libevdev_has_event_code(pEvdev->dev, EV_KEY, BTN_STYLUS) ||
libevdev_has_event_code(pEvdev->dev, EV_KEY, BTN_STYLUS2))
{
xf86IDrvMsg(pInfo, X_PROBED, "Found absolute tablet.\n");
pEvdev->flags |= EVDEV_TABLET;
if (!pEvdev->num_buttons)
{
pEvdev->num_buttons = 7; /* LMR + scroll wheels */
pEvdev->flags |= EVDEV_BUTTON_EVENTS;
}
} else if (libevdev_has_event_code(pEvdev->dev, EV_ABS, ABS_PRESSURE) ||
libevdev_has_event_code(pEvdev->dev, EV_KEY, BTN_TOUCH)) {
if (has_lmr || libevdev_has_event_code(pEvdev->dev, EV_KEY, BTN_TOOL_FINGER)) {
xf86IDrvMsg(pInfo, X_PROBED, "Found absolute touchpad.\n");
pEvdev->flags |= EVDEV_TOUCHPAD;
} else {
xf86IDrvMsg(pInfo, X_PROBED, "Found absolute touchscreen\n");
pEvdev->flags |= EVDEV_TOUCHSCREEN;
pEvdev->flags |= EVDEV_BUTTON_EVENTS;
}
} else if (!(libevdev_has_event_code(pEvdev->dev, EV_REL, REL_X) &&
libevdev_has_event_code(pEvdev->dev, EV_REL, REL_Y)) && has_lmr) {
/* some touchscreens use BTN_LEFT rather than BTN_TOUCH */
xf86IDrvMsg(pInfo, X_PROBED, "Found absolute touchscreen\n");
pEvdev->flags |= EVDEV_TOUCHSCREEN;
pEvdev->flags |= EVDEV_BUTTON_EVENTS;
}
} else {
#ifdef MULTITOUCH
if (!libevdev_has_event_code(pEvdev->dev, EV_ABS, ABS_MT_POSITION_X) ||
!libevdev_has_event_code(pEvdev->dev, EV_ABS, ABS_MT_POSITION_Y))
#endif
EvdevForceXY(pInfo, Absolute);
}
For interface 1 this code finds absolute axis, including pressure, but no
button marked stylus (it is marked as mouse button 1, but mislabeled as Back
by the kernel somehow), and so it decides on a touchpad. This single error
causes it to set relative mode and ignore any motion without pressure.
So, opinions? How should these flaws be patched? |
|
From: Nikolai K. <sp...@gm...> - 2015-01-19 19:49:08
|
Hi Mike,
On 01/19/2015 09:10 PM, Mike Sapsard wrote:
> I have just purchased a Ugee-1000L for use in Linux Mint 17.1, on an I7
> Toshiba laptop.
>
> It appears as three devices within Evdev and in MyPaint debug.
This is expected.
> The general info is in the attached zip file. The 8 keys on the left side
> and the 16 soft keys across the top are not accurately reported.
Thank you for the diagnostics!
> I see from the archives that you are currently working on this device.
>
> If I can help in any way with testing, please let me know.
Yes. Could you please try this experimental version of the driver:
https://github.com/DIGImend/digimend-kernel-drivers/archive/ugee.zip
Thank you.
|
|
From: Mike S. <mik...@gm...> - 2015-01-19 19:10:50
|
I have just purchased a Ugee-1000L for use in Linux Mint 17.1, on an I7 Toshiba laptop. It appears as three devices within Evdev and in MyPaint debug. The general info is in the attached zip file. The 8 keys on the left side and the 16 soft keys across the top are not accurately reported. I see from the archives that you are currently working on this device. If I can help in any way with testing, please let me know. Mike Sapsard |
|
From: Milan P. <mil...@gm...> - 2015-01-18 18:47:43
|
Hello Nikolai,
thank you for your comments. I added the missing <pop/> element.
With the 'digitizer eraser' button, I hoped to temporarily switch a tool
to eraser, but as you noted, that did not work. I reverted it to AC
Delete, which is probably the closest description I could find in the
HID Usage Tables document. Attached is both the kernel patch to current
master and the fixed descriptor XML.
Best regards,
Milan
On 12/30/2014 05:02 PM, Nikolai Kondrashov wrote:
> Hi Milan,
>
> On 12/30/2014 05:09 PM, Milan Plžík wrote:
>> if possible, could you have a look on attached patch/comment on any merge
>> blockers?
>
> Thanks for sending the patch!
> Sorry for the delay with reviewing this.
> I had some difficulty managing things in the project and might still do.
>
> It looks mostly fine, I have two comments only.
>
>> + 0x05, 0x0D, /* Usage Page (Digitizer), */
>> + 0x09, 0x21, /* Usage (Puck), */
>> + 0xA1, 0x01, /* Collection (Application), */
>> + 0x85, 0x11, /* Report ID (17), */
>> + 0x09, 0x21, /* Usage (Puck), */
>> + 0xA0, /* Collection (Physical), */
>> + 0x05, 0x09, /* Usage Page (Button), */
>> + 0x75, 0x01, /* Report Size (1), */
>> + 0x19, 0x01, /* Usage Minimum (01h), */
>> + 0x29, 0x03, /* Usage Maximum (03h), */
>> + 0x14, /* Logical Minimum (0), */
>> + 0x25, 0x01, /* Logical Maximum (1), */
>> + 0x95, 0x03, /* Report Count (3), */
>> + 0x81, 0x02, /* Input (Variable), */
>> + 0x95, 0x04, /* Report Count (4), */
>> + 0x81, 0x01, /* Input (Constant), */
>> + 0x95, 0x01, /* Report Count (1), */
>> + 0x0B, 0x32, 0x00, 0x0D, 0x00, /* Usage (Digitizer In Range), */
>> + 0x14, /* Logical Minimum (0), */
>> + 0x25, 0x01, /* Logical Maximum (1), */
>> + 0x81, 0x02, /* Input (Variable), */
>> + 0xA4, /* Push, */
>
> There doesn't seem to be a Pop for this Push. It will probably work this
> way,
> but that's not neat and confusing.
>
>> + 0x05, 0x01, /* Usage Page (Desktop), */
>> + 0x75, 0x10, /* Report Size (16), */
>> + 0x95, 0x01, /* Report Count (1), */
>> + 0x55, 0xFD, /* Unit Exponent (-3), */
>> + 0x65, 0x13, /* Unit (Inch), */
>> + 0x14, /* Logical Minimum (0), */
>> + 0x34, /* Physical Minimum (0), */
>> + 0x09, 0x30, /* Usage (X), */
>> + 0x27, 0x00, 0xF0, 0x00, 0x00, /* Logical Maximum (61440), */
>> + 0x46, 0xE0, 0x2E, /* Physical Maximum (12000), */
>> + 0x81, 0x02, /* Input (Variable), */
>> + 0x09, 0x31, /* Usage (Y), */
>> + 0x27, 0x00, 0xB4, 0x00, 0x00, /* Logical Maximum (46080), */
>> + 0x46, 0x28, 0x23, /* Physical Maximum (9000), */
>> + 0x81, 0x02, /* Input (Variable), */
>> + 0x09, 0x38, /* Usage (Wheel), */
>> + 0x75, 0x08, /* Report Size (8), */
>> + 0x95, 0x01, /* Report Count (1), */
>> + 0x15, 0xFF, /* Logical Minimum (-1), */
>> + 0x25, 0x01, /* Logical Maximum (1), */
>> + 0x34, /* Physical Minimum (0), */
>> + 0x44, /* Physical Maximum (0), */
>> + 0x81, 0x06, /* Input (Variable, Relative), */
>> + 0xC0, /* End Collection, */
>> + 0xC0, /* End Collection, */
>
>> + 0x05, 0x0C, /* Usage Page (Consumer), */
>> + 0x09, 0x01, /* Usage (Consumer Control), */
>> + 0xA1, 0x01, /* Collection (Application), */
>> + 0x85, 0x12, /* Report ID (18), */
>> + 0x14, /* Logical Minimum (0), */
>> + 0x25, 0x01, /* Logical Maximum (1), */
>> + 0x75, 0x01, /* Report Size (1), */
>> + 0x95, 0x08, /* Report Count (8), */
>> + 0x05, 0x0C, /* Usage Page (Consumer), */
>> + 0x0B, 0x45, 0x00, 0x0D, 0x00, /* Usage (Digitizer Eraser), */
>
> Does this really work? What happens if I press this button?
>
>> + 0x0A, 0x1A, 0x02, /* Usage (AC Undo), */
>> + 0x0A, 0x01, 0x02, /* Usage (AC New), */
>> + 0x0A, 0x2F, 0x02, /* Usage (AC Zoom), */
>> + 0x0A, 0x25, 0x02, /* Usage (AC Forward), */
>> + 0x0A, 0x24, 0x02, /* Usage (AC Back), */
>> + 0x0A, 0x2D, 0x02, /* Usage (AC Zoom In), */
>> + 0x0A, 0x2E, 0x02, /* Usage (AC Zoom Out), */
>> + 0x81, 0x02, /* Input (Variable), */
>> + 0x95, 0x30, /* Report Count (48), */
>> + 0x81, 0x03, /* Input (Constant, Variable), */
>> + 0xC0 /* End Collection */
>> +};
>> +
>
> Otherwise it looks good to me.
>
> Nick
|
|
From: Vikko O. <tc...@gm...> - 2015-01-11 15:47:52
|
Oh.. Okay then. I'll try to figure it out. For now, Ubuntu will do. Thanks a lot! Keep the great works! On Jan 11, 2015 7:09 PM, "Nikolai Kondrashov" <sp...@gm...> wrote: > Hi Vikko, > > On 01/11/2015 12:42 PM, Vikko Okviandho wrote: > >> The mouse works well enough. No problem encountered. >> > > Ah, good! > > I tried to compile the driver file in Manjaro to no avail. Here's the >> output in terminal >> $ make >> make -C /lib/modules/3.10.63-1-MANJARO/build SUBDIRS=/home/username/ >> Downloads/digimend-kernel-drivers-master modules >> make[1]: *** /lib/modules/3.10.63-1-MANJARO/build: No such file or >> directory. Stop. >> Makefile:10: recipe for target 'modules' failed >> make: *** [modules] Error 2 >> >> Anything missing? >> > > Yes, you need headers for your kernel version installed. I'm not a user of > Manjaro or Arch Linux and I couldn't find a definite answer how it should > be > done quickly, so you'll have to figure it out yourself. > > Nick > |
|
From: Nikolai K. <sp...@gm...> - 2015-01-11 12:09:58
|
Hi Vikko, On 01/11/2015 12:42 PM, Vikko Okviandho wrote: > The mouse works well enough. No problem encountered. Ah, good! > I tried to compile the driver file in Manjaro to no avail. Here's the output in terminal > $ make > make -C /lib/modules/3.10.63-1-MANJARO/build SUBDIRS=/home/username/Downloads/digimend-kernel-drivers-master modules > make[1]: *** /lib/modules/3.10.63-1-MANJARO/build: No such file or directory. Stop. > Makefile:10: recipe for target 'modules' failed > make: *** [modules] Error 2 > > Anything missing? Yes, you need headers for your kernel version installed. I'm not a user of Manjaro or Arch Linux and I couldn't find a definite answer how it should be done quickly, so you'll have to figure it out yourself. Nick |
|
From: Vikko O. <tc...@gm...> - 2015-01-11 10:42:53
|
The mouse works well enough. No problem encountered. I tried to compile the driver file in Manjaro to no avail. Here's the output in terminal $ make make -C /lib/modules/3.10.63-1-MANJARO/build SUBDIRS=/home/username/Downloads/digimend-kernel-drivers-master modules make[1]: *** /lib/modules/3.10.63-1-MANJARO/build: No such file or directory. Stop. Makefile:10: recipe for target 'modules' failed make: *** [modules] Error 2 Anything missing? On 11 January 2015 at 02:42, Vikko Okviandho <tc...@gm...> wrote: > I'll try tomorrow. I'll send the report along with the mouse trial. > > On 11 January 2015 at 02:41, Nikolai Kondrashov <sp...@gm...> wrote: > >> On 01/10/2015 09:19 PM, Vikko Okviandho wrote: >> >>> Err.. I didn't. I'll try it later. >>> >> >> That would be useful, thank you. >> >> BTW, can the patch applied to other distro as well? I have an >>> installation >>> of Manjaro. >>> >> >> It's not exactly a patch, rather just a driver. It should work on distros >> with >> kernels starting with 3.5. Please write, if it doesn't. >> >> Nick >> > > |
|
From: Vikko O. <tc...@gm...> - 2015-01-10 19:43:12
|
I'll try tomorrow. I'll send the report along with the mouse trial. On 11 January 2015 at 02:41, Nikolai Kondrashov <sp...@gm...> wrote: > On 01/10/2015 09:19 PM, Vikko Okviandho wrote: > >> Err.. I didn't. I'll try it later. >> > > That would be useful, thank you. > > BTW, can the patch applied to other distro as well? I have an installation >> of Manjaro. >> > > It's not exactly a patch, rather just a driver. It should work on distros > with > kernels starting with 3.5. Please write, if it doesn't. > > Nick > |
38 messages has been excluded from this view by a project administrator.
