Graphics tablet

I bought myself a graphics tablet – a Braun Tavla 5 (rebadged UC-Logic WP5540U (Genuis Mousepen)).

Connected to RISC OS, it appears to behave as a mouse until something else opens the USB port (at which point RISC OS stops paying attention – this may be useful to override the default behaviour).

The protocol seems quite simple. There are between six and 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.

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 appears to be the button press, with &00 being nothing, &01 being Select (tip), &02 being Adjust (lower pen barrel button) and &04 being Menu (upper pen barrel button). It is possible to have a barrel button (either) and tip at the same time, 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 minor position (changes a lot), and the fourth byte is the major position. Extreme left is &00 &00 and extreme right is &E3 &7F (which means the span is 0-32739, or a little over 2000 per centimetre (!)).

The fifth and sixth bytes are the vertical position from TOP to bottom. As before, the fifth is the minor and the sixth is the major. Extreme TOP is &00 &00 (note, top left is 0,0) and extreme bottom is &E9 &7F (span 0-32745, or 2700 per centimetre).

[in reality, it is unlikely that the array would be different in each dimension, plus it is unlikely to have such a high resolution – the box implies 2000 points per inch]

The seventh and eighth bytes, if they are present (they usually are) is for the pen pressure. The seventh byte is the minor pressure, and it is quite a bit more sensitive than drawing programs on the PC would imply. The eighth byte is the major pressure. Pressure is only reported if the barrel buttons are not 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

I don’t think it would be too hard to cobble together a program to fake the mouse pointer position, however I am not sure how to pass on the pressure level to RISC OS. It seems some programs (ArtWorks? PhotoDesk?) can work with pressure sensitive tablets, however I have no details on how this mechanism works. Unfortunately RISC OS’s mouse handling (in or out of the Wimp) has never been expanded beyond “pointer and buttons” (witness the hacks re. scroll wheel).

Why do what RISC OS can already do? Well, for a start RISC OS uses the entire size of the digitiser surface. The delineated inner area is smaller (the box says 5" by 4") which goes from &077F,&0D35 (upper left) to &737E,&75CE (lower right) with 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”. ;-)

I’m in holiday. But at home I have the old tripad software for a Robotron (Summergrafics bitpad one) tablet. Driver, macro recorder and so on. Not sure but I think the source is inside…
One of my “todo” things… try with ARMX6.

First steps with the old hard- and software on ARMX6. The driver module works only with Aemulor. Other problem is my board. I have a early Revision of the board with a wiring bug. I hope I find the time to fix.

Raik – does the driver have anything (stronghelp file?) to describe its API? It would be most logical to create a driver for my tablet (and maybe others?) using an API already known to RISC OS.

I mean yes (txt and Impression and paper) but only in German.
I search and I hope I find the german “maker”.

Edit: Take a look at your heyrick1973 mailbox.

Makes me wonder if I still have the stuff for our “PadDriver” stuff which did a range of non-pressure tablets. I think it was a sumagraphics thing too, but covered quite a few different tablets. I recall that it had special code in to handle some decidedly odd things that various RISC OS apps (eg. Artworks) did with co-ordinates. If there’s interest, let me know. I’m not sure what happened to the author though (he did Copernicus and a few other things).

Possibly interested.

I seem to recall some software (Photodesk?) works with a tablet driver (Eesox?). I’d like to find out if the API for that is known/documented. A Google search didn’t turn up anything.
It would be fairly trivial to devise my own API to hook into RISC OS, but if you can’t use PhotoDesk with it, then what’s the point?
The correct answer is for extended pointer-like devices to be a HAL device that can be chosen by RISC OS; so pointer, tablet, touchpad, etc can appear as devices that the user can choose to use to interact with RISC OS.
The more viable answer (given there isn’t exactly an API for scrolly-mice yet) is to pretend to be the Eesox driver and behave like it behaves.

I recall that it had special code in to handle some decidedly odd things that various RISC OS apps (eg. Artworks) did with co-ordinates.

While this could be problematic for me (don’t have ArtWorks), I can imagine there could be issues with a device that is capable of hopping around the workspace with no movement from here to there.

With my A5000/Risc PC I use the tripad with CAD and Photodesk and the Mouse is aviable at the same time.

I think we may have the sources to the PaintPal driver
I’ll have a look.

On step forward…

Thanks to Willi Theiss.

Raik & Rick: Any progress?

n.b. I do have the 32bit sources to:
!Graphire
!Tablet
!Strokes

I’ve done nothing with this. Can you send me any sources you have, please. I think it’ll be fairly simple to fake mouse position, but what’s the API for passing pen pressure to an app?

I’ll have to remind myself what rights I have to the sources.
It was a long time ago!

Another issue is the lack of anything to test with – PhotoDesk does not natively support pressure, it needs something added. The only other software I’m aware of that might support pressure is ArtWorks, and I don’t have that.

It’s a shame there is no public API document for such things. Though, to be honest, I think PointerV (or however one wishes to implement it) needs a huge overhaul to account for the various “pointer” options that are not a simple three-button mouse…

All this things are not a problem with the tripad driver. With my A5000 I use it with WorraCAD, a earlier Version Photodesk. It has a “three-button-support” and it allowed to use both (mouse and tablet) at the same time.
The API are aviable for free, I mean. Have I send? I search the old programmer but I not found.
I’m a bit busy, so the project paused.
I have a problem with the serial settings. I not found the time to reactivate my A5000 to check the details of the serial settings on it.

needs a huge overhaul to account for the various “pointer” options that are not a simple three-button mouse…

This sounds a great idea, even if it is for my own selfish requirements :@)

If it were accessible from outside the WIMP, then I’d love to put something like pressure sensitivity into my app…soft or hard detection to chose scrolling speed?

Also ability to use scroll wheel outside the WIMP would be good…still can’t work out why there is no non-WIMP interface for that after all these years of wheel mice.

Also ability to use scroll wheel outside the WIMP would be good…still can’t work out why there is no non-WIMP interface for that after all these years of wheel mice.

Nobody ever devised a new API. We can’t use OS_Mouse as adding extra registers would break older apps.

The ROLtd method was a bit of a bodge (magic values for extra info) but the ROOL method is worse. ;-)

I think we ought to devise a new SWI, OS_PointerPosition before anything else. Must support touch and pressure and multi point and relative/absolute positions…

And I thought I was the last person on earth using WorraCAD still.

Also ability to use scroll wheel outside the WIMP would be good…still can’t work out why there is no non-WIMP interface for that after all these years of wheel mice.

Nobody ever devised a new API […] Must support touch and pressure and multi point and relative/absolute positions…

There was a bounty set up for just such an activity, but looking through the internet archive it looks like it attracted a sum total of zero pounds and zero pence.

The overview of tasks involved in the bounty suggests it’s pretty involved – requiring touching the USB driver, kernel, and Wimp. I don’t know what the criteria are for reopening bounties (there’s no precedent), so for now it’s snoozing on the roadmap.

There was a bounty set up for just such an activity,

Not quite. That bounty looks like it was simply for “sanely” implementing scrollwheel support. That said, the current manky incarnation more or less works as it is, so long as nobody actually looks at what the code is doing to do that ;-) – so it probably didn’t figure on anybody’s wish list.

What I’m suggesting is to relegate PointerV and OS_Mouse to legacy status, and devise something that is capable of dealing better with non-mouse pointing devices.

We ought to be able to leave the Mouse_Click poll event intact, as there shouldn’t be any problem trashing a bit more of the block passed to the Wimp. A program cannot predict future poll events, so all 256 bytes of the block may be used to pass additional information which will remain invisible to older programs.

Thinking aloud now…

• For modern mice, we’ll need a way of reporting the scroll wheel activity.
• Some modern mice have additional buttons. Does RISC OS cater for those?
• For graphics tablets, we’ll need a way of reporting pen pressure.
• We do not need to cater for tablets using an inner work area as the pen-to-screen zone and parts of the outer work area as “hot zones” (that typically issue a keypress such as “Save” or “Print” or “Undo”). This is a matter for the tablet driver to deal with.
• Likewise, we do not need to cater for absolute / relative device positions. Again, it is a matter for the driver to deal with. All the API will provide is the “pointer position” as it does right now; however one should not assume a linear movement from point to point (as would happen with a mouse). This isn’t a big deal – my tablet appears to function as a regular mouse with RISC OS already…
• Likewise, we do not need to cater for calibration. Driver issue.
• But we will need to understand that X,Y,pressure may be repeated multiple times. I think fancy tablets like to claim tracking more points than people have fingers; not sure about the capabilities of hardware such as the Adafruit touch sensor; however the API should cater for a reasonable number of potential points.

Note that (potentially scroll wheel excepted) there is no requirement for the Wimp to actually do anything with this information. The important part is it being available. Rather like the situation with the multimedia keys on modern keyboards – they can’t be used by programs (such as DigitalCD) because there is no mechanism for getting that information into a task-visible form.

If it were accessible from outside the WIMP, then I’d love to put something like pressure sensitivity into my app…

There’s the problem, though. I gave a short program (up towards the top) that will provide you with a co-ordinate, a button press, and a pressure. You could do something similar yourself, but wouldn’t it be better to have a consistent system-wide API for this sort of stuff?

Just threw this together in preference to doing “real” coding. Too tired to concentrate on stuff like that tonight…

DIM blk% 12
col% = 127
MODE 28
d$ = "USB12" : REM <----------- CHANGE AS REQUIRED
i% = OPENIN("devices#endpoint1:"+d$)
ON ERROR CLOSE#i% : PRINT REPORT$+" at "+STR$(ERL) : END

GCOL 0, col%, 0 : REM Initially mid-green

REPEAT
  REM Have we data?
  d% = EXT#i%
  IF (d% > 0) THEN
    REM Read data (should be eight bytes)
    IF (d% > 8) THEN d% = 8 : REM Clip it to be sure!
    FOR l% = 0 TO (d% - 1)
      blk%?l% = BGET#i%
      REM Byte #1 = &09
      REM Byte #2 = Button (1=tip, 2=barrel lower, 3=barrel upper)
      REM Byte #3 = Horizontal minor
      REM Byte #4 = Horizontal major (range 0-32739; 0 is LEFT)
      REM Byte #5 = Vertical minor
      REM Byte #6 = Vertical major (range 0-32745; 0 is TOP)
      REM Byte #7 = Pressure minor
      REM Byte #8 = Pressure major (range 0-1023; writing is ~100)

      IF (blk%?0 = 9) THEN
        REM Only do this if sync byte correct

        REM Barrel LOWER makes the circle darker
        IF ((blk%?1 AND 2) = 2) THEN
          col%+=1
          IF col% > 255 THEN col% = 255
          GCOL 0, col%, 0
        ENDIF

        REM Barrel UPPER makes the circle lighter
        IF ((blk%?1 AND 4) = 4) THEN
          col%-=1
          IF col% < 0 THEN col% = 0
          GCOL 0, col%, 0
        ENDIF

        REM Barrel TIP is for drawing
        IF ((blk%?1 AND 1) = 1) THEN
          REM Get positions
          xpos% = (blk%?3 << 8) + blk%?2
          ypos% = (blk%?5 << 8) + blk%?4
          REM Convert to OS units
          xpos% = xpos% / 25.5773437
          ypos% = 1200 - (ypos% / 27.2825)
          REM Get pressure
          pres% = (blk%?7 << 8) + blk%?6
          pres% = pres% >> 5 : REM Set size 0-31
          CIRCLE FILL xpos%, ypos%, pres%
        ENDIF
      ENDIF
    NEXT
  ENDIF
UNTIL 0
END