nanogui: Nano-X touchscreen
Subject:
Re: [nanogui] Re: Nano-X touchscreen
From:
Jordan Crouse ####@####.####
Date:
25 Jun 2005 01:48:41 +0100
Message-Id: <42BCA9CD.4080601@cosmicpenguin.net>
ER -
Greetings.
> : : struct ts_event {
> : : short pressure;
> : : short x;
> : : short y;
> : : short miliseconds;
> : : };
> : : when I use this in the header file, I get an error:
> : : "Wrong number of bytes 0 read from touch panel expected 6
Well, there are a couple of things here. First, the read is returning 0
bytes, which is unexpected, because we really don't expect to be in
PD_Read unless there is something to read on the line.
Does this message print out continuously, or just on an event (say when
you tap the screen).
The second problem is that the structure that you sent doesn't match the
size of the structure that the code is reading. The number following
'expected' is just a sizeof(struct ts_event), so if your structure was
being used, the sizeof(ts_event) would be 8.
At one time, struct ts_event was different for different devices, so
each device had its own header file that defined struct ts_event,
complete with an evil #ifdef arrangement at the top of mou_touchscreen.c
- Make sure that your header is the one being used.
> It looks like I'm alone on this list. I remember subscribing a few
months ago and withdrew after realizing I might be along at this.
> If no one have an idea, perhaps someone can explain the MOUSE_RAW,
ans _TRANSFORM and how nano-X looks at the touchscreen interface. Maybe
I can use the tslib in this but I'll need to understand how nanoX talks.
>
Well, MOUSE_RAW is really pretty simple. The whole point was to provide
a more generic method of handling calibration and filtering of incoming
events on absolute devices like touchscreens. These devices need a bit
of math applied to them to map them to the screen resolution, and most
of them also need some jitter filtering applied.
I decided that the best course of action would be to have a client based
transform utility that then had the responsibility of passing in the
transform data to the server upon load. This was done to mainly get the
ugly math out of the server, but also to remove the policy of figuring
out where the calibration data was stored, as well as not force a server
reload after a calibration.
So we have two scenarios - when one is calibrating, one wants raw data
so they can do the calculations. After the data has been computed and
loaded into the kernel, then the client app would want the cooked data
so the touchscreen would then act like a pointer.
Thats the point of the MOUSE_RAW flag - in RAW mode, data is passed
straight from the touchscreen to the client with no intermediate
cooking. But otherwise, the data is put through the transforms and
comes out as a sane value (with hopefully as little jitter as possible).
The drivers come in on the far side of this - they are responsible for
reading the data, and passing to the engine. mou_touchscreen is one
driver that you can use (it was created because there were four or five
drivers that all did the same basic thing), but you don't have to use
it. Feel free to create your own driver, as long as you can read the
device file and pass the correct values to the server for processing.
Hope this helps,
Jordan
