Rick's b.log - 2015/07/29
It is the 21st of November 2024 You are 3.135.200.121, pleased to meet you!

Graphics Tablet - Braun Tavla 5 (UC-Logic WP5540U)

It worked pretty well. I have contacted the company responsible for ArtRage to ask if it is possible to register the older version (the latest doesn't work with XP any more, and at any rate I have very little room left on the SSD where "Program Files" lives, thanks to this machine using SSDs instead of a harddisc). I'll let you know what they say.

The tablet itself:

The quoted work area of the tablet is 5" by 4" (12.7×10.2cm), however this refers to the inner rectangle. The complete area (including outer hotspots) is 15×12cm (5.9×12.7"). The resolution is quoted at 2000 lines per inch, but in reality is a little less as the precision is quoted as +/- 0.25mm (0.01"), or 100 points per inch, or about 40 points per centimetre. The precision is reasonable, as I don't think I can control my hand to within a quarter of a millimetre.
The pen tip pressure has 1024 levels. While it seems some software requires a moderately heavy touch, the truth is that the pen is quite sensitive. You can see this in the data coming from the device.

Of course, my level of drawing is akin to that of a four year old, so the girl above was drawn by epic cheating. I simply put the page over the tablet's work surface, and...

I was interested to see how RISC OS would fare. It detected the tablet as a mouse - the built in HID block lists three different options - digitiser tablet, mouse, another sort of mouse - so I'm guessing it just failed the first two and decided it know what to do with the last one. RISC OS does not know about the work area and hotspots, so it mapped the entire work area to the screen. The tip was the Select button (tap it to do something). The lower pen barrel button was Adjust, and the upper barrel button was Menu. This makes sense to Windows which has only traditionally had a left and right mouse button, however on RISC OS it might be more logical to swap them around.

The problem with RISC OS is that our mouse API is over a quarter of a century old. And since it is specified in the PRMs that the OS_Mouse call corrupts (returns data in) registers R0-R3, we can't arbitrarily provide more information as software won't be expecting the registers to be altered. We could, perhaps, extend the Mouse Click Poll Event (as the block on entry should be 256 bytes - and you can't stash private data in there as you don't know what event the Wimp will return), but nothing has been decided as of yet.
Accordingly, scrolling via a scroll wheel is a bit of a hack (as in, a low level driver calling Wimp SWIs to 'fake' a scroll - yuck!) and don't even contemplate such luxuries as multitouch.
Likewise, there is currently no OS-wide mechanism for dealing with tablet (or finger?) pressure - there is a de facto 'standard' designed ages ago by Eesox but this does not appear to be documented anywhere so being compatible with it will be somewhere between difficult and impossible.

The device, when connected, presents three sets of HID information and RISC OS falls back to the "mouse" option. However, the protocol for the data is quite simple:

The protocol is quite simple. There are between six and eight (usually eight) bytes returned per event. Events come in as necessary, and when in use could be around 35-45 per second; the box suggests up to 125pps though I've not seen this in testing.

• The first byte is &09. Note that if a lot of rapid work is being done, it is possible that DeviceFS may receive and buffer multiple requests and return them together, so this can be used to synchronise.
  
  
• The second byte is the button press; with &00 being nothing, &01 being Select/Left (tip), &02 being Adjust/Right (lower pen barrel button), and &04 being Menu/Middle (upper pen barrel button).
  It is possible to have a barrel button (either) and tip at the same time (&03 and &05), but it doesn’t appear possible to have all three active at once. I don’t know if the protocol doesn’t permit this – it seems possible to active both barrel buttons at once but the result is &00, however interestingly if I activate both barrel buttons and press the tip, the result is &02 – so this may be a hardware bug?
  
  
• The third and fourth bytes give the horizontal position from left to right. The third byte is the low byte and the fourth byte is the high byte.
  Extreme left is &00 &00 and extreme right is &E3 &7F, which means the span is 0-32739.
  
  
• The fifth and sixth bytes are the vertical position from TOP to bottom. As before, the bytes are backwards with the fifth being the low byte and the sixth being the high byte.
  Extreme TOP is &00 &00 (note, top left is 0,0) and extreme bottom is &E9 &7F giving a span of 0-32745.
  
  
• The seventh and eighth bytes, if they are present (they usually are) is for the pen pressure. The seventh byte is the low byte, and it is quite a bit more sensitive than various drawing programs on the PC would imply. The eighth byte is the high byte.
  Pressure is only reported if the no barrel buttons are being pressed.
  No pressure is &00 &00 and maximum pressure is &FF &03 (span 0-1023). My normal writing would seem to be around &5F.

The following program will dump the raw data:

MODE 28

d$ = "USB7" : REM <----------- CHANGE AS REQUIRED

i% = OPENIN("devices#endpoint1:"+d$)

ON ERROR CLOSE#i% : PRINT REPORT$+" at "+STR$(ERL) : END

REPEAT
  d% = EXT#i%
  IF (d% > 0) THEN
    FOR l% = 1 TO d%
      b% = BGET#i%
      PRINT RIGHT$("00"+STR$~(b%),2)+" ";
    NEXT
    PRINT
  ENDIF
UNTIL 0
END

Although it isn't necessary as RISC OS can already use this as a mouse, it shouldn't be hard to cobble together something to fake the mouse pointer position. Conveniently, RISC OS now has a method of reporting absolute pointer positions, however as mentioned earlier, there is no openly defined way of providing pen pressure to the system.

Another reason for a custom driver would be because RISC OS uses the entire digitiser surface. The inner work area is smaller than the tablet surface and so would need to be scaled accordingly, and clipped if necessary (the work area goes from &077F,&0D35 (upper left) to &737E,&75CE (lower right)). Additionally, there are sixteen marked out hotspots around the edge, although obviously the exact position will depend upon which version of the tablet this is (the Braun one is laid out slightly differently to the UC-Logic original). At any rate, it might be nice to map hotspots to keypresses, like... "Undo"! ☺

Your comments:

Merrolin, 5th July 2016, 00:08

If it's compaptible with Windows 7, it's also compaptible with windows 10 ? And does it work great on Flash CC ?  Please answer quickly.

Rick, 5th July 2016, 00:43

You know in the time it took you to write this - you could have Googled. Here's the drivers, there's one for Windows 8. No idea about Win10. And I don't know what Flash CC is. http://www.braun-phototechnik.de/en/downloads/Software-Treiber/~ did.14~nm.15~nc.21/download-14.html (if the blog software put any spaces in that URL, you'll need to remove them)

Merrolin, 19th July 2016, 22:34

Oh well I googled it, but I haven't found anything. But in fact, I received the tabled in time and it works perfectly on most of the softwares I have ! So I can say it works great on W10. The driver is also compatible !  (Sorry for answering so late, I was enjoying it making animations xD)