 All right, I guess we can start. Hi everyone, I'm Nikolay Kondrashov, and I'm an open source developer. I work at Red Hat. I also do electronics and embedded as a hobby. And I'm, oh, that font is wrong. Maintainer of DigiMent. But let's hope this works. So we don't have any amplifications. I'll try to speak louder, okay. So I'm a maintainer of the DigiMent project which this presentation is all about. So generic tablets. What are generic tablets? What I mean by that? Basically, any graphics tablets which are not made by vacuum because many think that vacuum is the only manufacturer there is. It's just not true. And those generic tablets are mostly manufactured and built by original equipment manufacturers in Asia. Then they are rebranded and sold under many, many different brands. And this list here is maybe a half or a third of the names that you can find. So they can be like very small, barely usable. I don't think anybody produces those small tablets anymore because, well, you can't do much on them except sign something. There are tablets which are very visible on the screen, which are very cheap and you can do a lot with them. And they are very popular. There are some curiosities which are experimental or they're just made in single model and didn't go anywhere from the same manufacturer like this. I think you can only buy it in Japan these days. And it's curious because the pen has no battery and it has tilt detection and I think they are licensed in the technology from vacuum. There are also huge these wireless tablets. For example, this one is not supported by Linux at the moment. And there are even tablet displays. This one is 27 inches in diagonal and has tilt detection and I don't even know if vacuum produces anything that big like any synthics or anything. And this costs like just a thousand dollars. So why do these things? Why make drivers for them and why care about them if vacuum is usually better? So the reason is that plenty of people can't afford vacuum especially people in poor countries and people who just try in their hand or try to become an artist or just want to see what it's all about and see what will happen. Students of course in schools. But for me it was the same people who would run Linux instead of buying Windows and all the graphical applications that go there. So for me it was mostly for fun. So the Digiment project was founded in 2008 and it focuses on making the non-vacuum graphics tablets work on Linux. And that was mostly me. But there were people coming and going and staying for a shorter, longer time. So the story is a bit long one. So I got a present in 2005 for my birthday and whoever gave me that present checked with the shop assistant if that tablet works on Linux and the shop assistant said it does. So they gave me that tablet and obviously it didn't. So I got curious and I browsed the internet a little bit and I found somebody hacked an Aptik driver to work with wizard pen tablets which are even older than mine from Genius. It was a student from Czech Republic and I took a look at it and I also hacked on it and tried to figure things out and I made it work with my tablet and a bunch of others which were very similar and me and him and a bunch of other people supported that driver for a while. So this was my tablet. But the thing was that basically that driver tried to cope with the garbage that Kernel was sending for that tablet because Kernel got confused by what the tablet told about itself and this driver still exists and I think it's in Ubuntu Launchpad right now and people still try using it and it still works with some tablets but these days it wouldn't work with many new tablets very well I think. So I thought perhaps fixing the kernel would be the right approach and I created this DigiMent project on sourceforge. Then so looking at the kernel I saw that the... some drivers in the kernel were basically just fixing up a little bit the report descriptors which are supposed to define in which way the tablets report the events. So I thought perhaps I can just, you know, instead of fixing them up a little just rewrite them. So I had to figure out how these report descriptors work and there were basically a few of them so I had to figure out how these report descriptors work and there were basically no editors for those report descriptors you had to craft them yourself or use the official report descriptor tool which is not that good and runs on Windows it could work on Linux but it wasn't that good and wasn't obvious so by doing that tool I learned a lot about report descriptors and was able to proceed so I made also a bunch of tools to dump the data from those tablets and I started hacking on the kernel so I didn't have the money to buy all those tablets so I went around the computer shops in my city and I asked if I can try them with my laptop so I took some dumps and I went home and made drivers and came back and asked them to try again so I made a bunch of them working this way and the general advice on that thing just go into a big shop like you know middle market actually meant to a middle market or you know like you know branch shops like the franchises they don't usually care much and say like I want to try this tablet can I try and they have them on display like lying there so you just plug them in or you can do it with another device like any input device most likely so yeah after this I was publishing those kernel patches and saying that you can make them work this way and I had to build my own kernels or like put the patches out because there was the only that way so people started coming and asking if they if I can make other tablets work and I talked to some people like over the changed e-mails and made them work I send them patches or upload the kernel somewhere and they would test it and they would come back and then test it it was obviously pretty tiring sometimes I also wrote to the manufacturers of some of those like the actual OEMs and I got a response from Baltop and they sent me three tablets so I made drivers for those in 2014 it became obvious that South Forge wasn't a very good place to host the open source project anymore and their service deteriorated and I was going down so I moved to GitHub and then a nice thing happened the kernel started supporting out of three heat tablets drivers pardon and asked for a little bit more support so that I can do my thing with them so it became possible to make an out of three driver package which I did and got more tablets supported and some people came and contributed so by 2016 it became like you know same thing all over again like all those tablets are in some way the same at least they looked to me already so I decided perhaps I should take my leave from it and I wrote a bit of post on the internet and said like okay I'm stopping doing this so if anybody wishes to step in and take over would be nice and I can help you so several people showed up and said like they are really interested and they would like to help but I told them what they can start looking into but I haven't heard from them since maybe one person, an assistant person wrote to me several times but then they eventually disappeared too but at the same time there were people coming like contributing for their own tablets or just doing their thing so in 2017 one Japanese company wrote to me and said like you know we are selling those cheap PCs with these cheap tablets running Linux to people who don't have much money in Japan and we really said that you stop doing this can you continue and we'll help you with the help of one of the OEMs so I thought about it for a while and said okay we can think of something and then later there was another company who needed a driver for a specific tablet for their product so they also agreed to pay me money and then I thought well having money for this work is nice and I thought maybe I should promote it a little more so I put up Patreon and people started coming and giving me some money and here I am promoting my project so why don't these tablets work right away so first of all most of the manufacturers they care about Windows only obviously and Windows generic human interface device driver doesn't work exactly like the one in Linux and it's not that good in some respects I think the human interface device specification is complex and vague and it doesn't help very much people who just want to make a device and write drivers just like from nothing and OEMs have no time for that especially those in Asia they just want to push the devices and made them as good enough to be sold to Windows users and that was also the idea in the Linux community that Wacom is the only graphics tablet there is so one of the main things that I noticed regarding the generic HID driver is that those tables they often have several report IDs in the report descriptor and for each report ID they sometimes have similar devices reporting the same data and Windows apparently has no problem with that but Linux tries to do its own thing and instead of reporting them with the same event code to the user space they kind of see repeated usage and report descriptor and they say well we have to separate those so let's just add some number to the event code and let's report them with some weird event code which doesn't make sense but we'll get some data to the user space that's actually what let us in VisitPen driver get that data but on the other hand perhaps we wouldn't need that VisitPen driver maybe it could be done some other way anyway so to work around that there is a Quirk and the generic HID driver which is called HID Quirk multi-input which basically creates an event device for each of the report descriptors for each of the report IDs in the report descriptor and many devices require that fix and some of the devices were fixed by just adding that Quirk to the kernel so what I noticed in the report descriptors of some of those tablets as they became bigger and bigger and they gained resolution is that the manufacturer started limiting the logical extents to 16-bit signed integer so they don't go higher than 32K and that was repeated across several models so I suspect there is some problem with the default with the generic HID driver and Windows which prevents them from using 32-bit integers which you can do that in the report descriptor and if you want to have a higher resolution you will have to therefore write a custom driver because the generic HID driver cannot handle that apparently so then there is the human interface device specification and it's 97 pages of description of the report descriptor language which allows you to specify which bits will mean this or that and how to parse that data it is rather vague again and you should know how to use it before you can do something with it you should know what you want to say and that's why there are 767 pages describing how to define specific devices like CRT monitor controls or joysticks or mice or medical devices or keypads and everything for each of those there is a few pages or document describing how you should use that language to describe that device and what these particular bits will mean so 8 of those pages define digitizers or graphics tablets which is not much if you consider that 3 of them are examples of report descriptors and it looks like the USB implementer forum is not working here very well and it looks like the designers of those drivers or devices they first make a driver then the device and then just describe it and submit that document from implementer forum so that they can get a certification back and they pay for that so it's hard to argue with them from the perspective of the implementer forum but it's just my guess I'm not a member of the USB implementer forum so the official report descriptor tool that the usb.org has runs on Windows as I said before and it is confusing to use it doesn't work very well and there is at least one case where it misinterprets the specification and it stores the unit exponent incorrectly and as a result many devices store it incorrectly in their report descriptors and now this is a standard defector which differs from actual specification so since the USB implementer forum is a consortium of manufacturers of devices and they are all paying members and they pat each other on the back to certify those devices users don't win from that and implementers like the third party implementers of the drivers have a hard time so, oh boy, yeah so these Asian original equipment manufacturers they have a hard time following all that and they don't so as I said already these edges in the same report descriptor and the different report IDs is what causing the problem Linux then it's not clear from this HID specification how you should report those buttons on the pen there is an example with just I think one button on the pen but if you have two you don't know what to do and all those tablet manufacturers they just try to emulate the mouse so they have two buttons on the pen and one company tries to report it this way another one that way which doesn't work very well then buttons on the frame of the tablet they are reported usually as a general purpose keyboard and then you press a button the device generates a scan code for the keyboard that like says like undo is control Z and zoom in works in Photoshop for this key and doesn't work on some other one and change brush is the special key combination in Photoshop again or in some other application that's all in the default mode without initializing tablets but this is what they do and because of the because they don't understand the specification very well because of the the official report descriptor tool being a little broken there like fun stuff like the coordinates being reported in cubic terra inches in the pen so yeah it basically says in the report descriptor cubic terra inches tenths of cubic terra inches but the tenths of cubic terra inches that comes from the report descriptor tool and cubic inches is basically they thought maybe that makes sense I don't know I think they try to scale the units somehow and something work and but then some people just give up and they say oh I don't care about report descriptor just stuff it with you know vendor use edges vendor stuff and everything they just don't make sense to HID driver at all and then yeah there's some more so tablets in the default mode when you plug your tablet in they become like crippled or useless because they require initialization to get the full resolution to get the buttons reported not as you know scan codes but as generic buttons you can like some of those manufacturers they use some same methods like send a feature report that at least something that would be according to HID specification but some others like use logic they you have to request a string descriptor and in response you get binary data instead of a string and in that binary data you have the tablet logical extends resolution number of buttons and all that stuff and you can request other string descriptors string descriptors and you get model numbers and something like that and also when you get the report descriptor with the parameters you somehow enable the tablet in the fully functional mode and after you some of those tables after you initialize them they start reporting the full data and everything but it is no longer in the format which would be suitable for describing with the report descriptor so it's not any longer according to HID specification so the mentality of vacuum is the only graphics tablet leads to people not testing any other tablets and I've seen applications, toolkits and drivers getting broken over time in various aspects with those tablets and the tablet like which has still detection basically the stack when I got the first one the input stack wasn't prepared for anything except vacuum and the whole stack didn't actually care about what those numbers were regarding and they just somehow adjusted their applications and everything and when I asked around what does that mean and everybody said well I don't know maybe angle maybe something and actually tried to measure input from one of the vacuum tablets and it was interesting because there was certainly some processing done somewhere on the way in the vacuum stack and I had to adjust the input from that one tablet which reported to look like vacuum so that it would work then there is this norm vacuum tablet configuration tool and already by the name you know where that is going there is no generic you know like just a tablet configuration tool any good only vacuum and another problem with it is that it uses sleep vacuum which doesn't want to work with tablets that just come like through the door and say hi I'm the new tablet you have to add enter to the library database so that it would recognize the tablet and allow you to configure it even if you use the vacuum driver on top of the kernel driver like the vacuum XORG driver it will still say I don't know anything there is no tablet connecting but you can configure that tablet then using the command line tool which is not convenient for everyone so if you work on any of those on a driver or on an application or on a tool kit get a couple of those tablets and just keep them around and test from time to time it will help so we have the out of three driver package which is called Digimand kernel drivers and it's very nice to have that because it's much easier to get it to users and for users it's much easier to install it than a full kernel or patches to the kernel and it's faster to develop and it's also easier for people who've never coded for kernel just get it and start hacking at it and just say make and make install and then you can play it is a bit of a hassle to sync with upstream some parts have to be different and we only keep modules which we need there which we have newer drivers for and try to keep all the difference minimal although when you need to do like some kind of refactoring that becomes hairy which is the case right now we have to copy some private definitions from the kernel and that's some compatibility markers but otherwise it's possible and in general very nice to users and developers there is one one trick to it in that if your custom driver that is out of 3 already has custom driver in the stock kernel then you can just use mod probe to override it and say like refer the driver from the extra directory or out of 3 driver then it works fine but otherwise the generic hid driver has a list of those vendor and product IDs which have a custom driver and if your tablet is not there then the generic driver never lets go and just says like ok I'll be handling it then since there are no custom drivers so we have a bunch of udev rules in the script which checks if there is a out of 3 driver installed which handles those tables and then rebinds it using the SSFS so make it work I obviously cannot describe all the ways which you can go to make your tablet work or somebody else's tablet work but this is one general way which might work in many cases so first of all you have to find out your device parameters what it can do, what it can report then you have to figure out if there is any initialization necessary and then go back maybe one step and then repeat then you I would recommend going with writing report descriptor instead of creating all the event codes for yourself and the driver and you might need to tweak some input bits so that they would fit the report descriptor and the in the kernel events tidy up event devices and contribute so here is in detail so to find out device parameters you can just dump the reports that the tablet sends and see what the possibilities are what happens when you press this button on that button and move it up and this way or that way or press it and everything that's very helps a lot this way you can find the maximum and minimum coordinates and the pressure range and the tilt if your tablet has it if this table will require initialization then you might have problems like your resolution will be limited and your range that you find this way will be different then you need to do initialization and then check it again and then also read the seller or manufacturer their specs because they might sometimes be different with what you see because you haven't initialized it or missed something but they can sometimes be different because manufacturer is you know a little line a little bit like with the pressure resolution and sometimes or something happens and then you will need also to find the drawing area size that you can derive the resolution from the physical resolution how many lines so here's an example of the dump made with USB dump for your tablet in default mode you would plug it in without the driver and you can see that the pen events are reported with report ID9 and there are buttons reported this one here you can see one here is basically meaning that the pen tip is on the tablet and touching and pressing but there is no proximity bit the tablet basically doesn't save when pen enters comes close to the tablet and the tablet can start reporting valid data and that is important for many drivers right now earlier the graphics stack and the whole input stack used to work with just the tablets without proximity reports but nowadays I hear reports that it doesn't work anymore okay something messed up here so you can see there are x coordinates y coordinates and the pressure that is pretty easy but you have to remember that this is all little end in so the lowest byte comes first if your tablet already reports everything you need you might not need to do any initialization you just need to check if you have the resolution and frame controls reported the way you want them to make a driver but if not many tablets nowadays are made using usologic chipsets and it's a good bet to try the usologic probe tool from our github organization and if it gives you any you know meaningful results and if you see that the reports change after you run this tool that means you're in luck and if that doesn't happen you can try the valve and chi methods which I haven't seen quite a while so probably they are not used anymore by anybody otherwise you will have to see the usb traffic from the windows driver and try to figure out what's going on and all of those requests are initializing the tablet so after initialization it's looking a bit better after initialization you might see completely different well slightly different picture in this case you see for example another neon tablet but it's similar for many of them you see that the port ID has changed you see that the coordinates can get another extents go higher and you can see in this case that there now is proximity report here and the pen goes out of proximity so this here the person lifted the pen this button got released then they removed it from the tablet completely and this changed but in this case the proximity bit goes one when you remove the pen so it's kind of inverted and I think it's against what the HID specs describe so next I would suggest if usologic probe worked then quite likely you will not need to write any report descriptors because in the current driver we generate our own report descriptors based on the parameters that you retrieved from the tablet you will just need to add your tablet to the list of the proper place in the big case statement otherwise you will probably need to learn a little bit about report descriptor language and read the spec and also look at the report descriptors that we have in our tablet database repository and look at them in the kernel as well so they give you some idea of what you can write there you can use HIDRD convert or some similar tool of which there are many now to make your own report descriptor and then you can use the report fix up handler in the kernel driver to fit that report descriptor to the generic HID driver so you can go from the report descriptor which you got from the tablet and dump it with USB HID dump or you can get that from the C's kernel debug tree for HID devices as well if you're using HIDRD convert you can convert it to XML sorry about that but it's currently the one two-way format that HIDRD supports and you edit the report descriptor the way you need it to work and convert it to code and paste that into your C file so sometimes you might need to tweak the input bits for example some tables can report garbage when you remove the pen from the surface far enough or for the pressure fields or some of the tables can start reporting the data in the way which is incompatible with HID specification you can't write a report descriptor for that so one way that we did before was to create an extra report descriptor and then change the report ID on the fly so that kernel thinks that there is a separate report ID and then we can write a separate piece of report descriptor for that or in the case of Alt-Op series we needed to translate the tilt reports and that's where you can do it or like convert that in-range bit that we just saw it would be nice to use this if you could for example, mask out the interfaces that don't produce anything some tables have like two or three interfaces but actually use only one or two maybe those other interfaces are for something else which we didn't figure out but then if you leave them be they will create an input device which never produces anything and then users get confused so if you return in there for those devices in the probe handler then that device will not appear then you can modify device names, event device names in the input configured handler which we do for use logic tables so that your device names will correspond to what they represent like here so it can look like this so user opens game for any other application and he sees a bunch of input devices named like this and which of those will depend you don't know they'll have to go through and click all of them and figure out which one will work and then some of the application got confused they tried to match the device by name but it was at some point so if you mask some of them out and then use that handler to add a little bit of clarification to the device that would be of much help so you can contribute to the demand kernel drivers when you make your tablet work and this way you get feedback faster and get your users faster and generally be able to make your driver faster you can contribute to the kernel directly of course but in either case you will need to follow kernel coding style and keep changes and commits nice and clear and logically separate so and there are those little things on the tablet and I had users ask me many times these don't work or how do I make them work so normally those are not actual buttons there it's just an area on the tablet which the windows driver sometimes can handle and you know I can relate short cuts to make that work or let you assign some shortcuts to that I think they are genuinely useless because you cannot feel them on the surface of the tablet compared to those actual buttons there so you have to look on the tablet and then look on the screen and on the tablet to see what's going on so don't bother about those sort of just gimmicks that manufacturers put like to sell more tablets so that's all I think except if you really want to you can become my patron supporter and get those nice stickers here right away so thank you everyone any questions yes do you actually have time to use those tablets by yourself or is it only coding to make them work no I used my tablet several times after I made the driver work and I tried to draw but I'm not a professional artist or anything so I found making drivers more interesting yes I guess you've got a list presumably so we can check first and then voice up the works yeah there is the website here where there is a little database of tablets which are supported and with versions of our drivers and the upstream kernel which support them so that might help in general yeah there's also like some things that manufacturers do be careful about that for example they change the insides sometimes and they don't change the name or they might change the name but slightly like Huion recently released a new line of tablets which changed the protocol quite in a quite noticeable way in the initialization sequence so and they added to the names like plus or 2048 or something like that otherwise leaving the name the same and lots of people got confused and there is work that needs to be done and people come and ask those tablets to work all the time anybody else yes it's all about USB here do you have any experience with serial tablets I think that by the time I started these other tablets were already quite dead so I had a few people come and ask me about serial tablets when I started but afterwards nobody came so I anybody else yes yes yes there are plenty of interfaces there are interfaces in the toolkits like Nome and Qt for that which you can use I have not never used them but I had time to look at them when something broke but it was quite a while since something broke in a toolkit so I don't remember how they work you can talk to the ex-work directly for example I don't know there should be some APIs to do that yes most tablets detect the pen when you hover and you don't touch that to move the cursor some drivers like the Libinput driver for example recently at least added the filtering of very slight touch and it doesn't register if you touch the surface a little it doesn't register a button click so you can kind of drag it a little bit and then press harder to make it work anybody else ok thanks everyone