I’d like to find out if the API for that is known/documented.
#PHOTODESK SIMILAR DRIVER#
I seem to recall some software (Photodesk?) works with a tablet driver (Eesox?). At any rate, it might be nice to map hotspots to keypresses, like “Undo”. 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). Why do what RISC OS can already do? Well, for a start RISC OS uses the entire size of the digitiser surface. Unfortunately RISC OS’s mouse handling (in or out of the Wimp) has never been expanded beyond “pointer and buttons” (witness the hacks re. It seems some programs (ArtWorks? PhotoDesk?) can work with pressure sensitive tablets, however I have no details on how this mechanism works.
#PHOTODESK SIMILAR HOW TO#
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.
The following program will dump the raw data: MODE 28 My normal writing would seem to be around &5F. No pressure is &00 &00 and maximum pressure is &FF &03 (span 0-1023). Pressure is only reported if the barrel buttons are not being pressed.
#PHOTODESK SIMILAR PC#
The seventh byte is the minor pressure, and it is quite a bit more sensitive than drawing programs on the PC would imply. The seventh and eighth bytes, if they are present (they usually are) is for the pen pressure. Extreme TOP is &00 &00 (note, top left is 0,0) and extreme bottom is &E9 &7F (span 0-32745, or 2700 per centimetre). As before, the fifth is the minor and the sixth is the major. The fifth and sixth bytes are the vertical position from TOP to bottom. 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 third byte is the minor position (changes a lot), and the fourth byte is the major position. The third and fourth bytes give the horizontal position from left to right. 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?
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. 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). 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. Events come in as necessary, and when in use could be around 35-45 per second the box suggests up to 125pps. There are between six and eight bytes returned per event. I bought myself a graphics tablet – a Braun Tavla 5 (rebadged UC-Logic WP5540U (Genuis Mousepen)).Ĭonnected 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).
0 kommentar(er)
