Gingerbread-x86: BOARD_USES_TSLIB usage

[rdg]

Hi,

First of all, thanks for the great job the Android-x86 team has done.

My target is an Atom-based device (US15W + SHC) equiped with an eGalax
(EETI) touchscreen, Intel 82874 (e1000) Ethernet and currently a
Ralink-based WLAN card. The device also have a ublox GPS receiver and
a Cinterion 3G modem. It's "hard disk" is a CompactFlash and it can
boot from USB devices.

I installed the Gingerbread-x86 sources and succesfully compiled a
clone of the asus_laptop iso image.

This iso image was installed on an USB key using unetbootin (it seems
the basic live-USB method does not work for me.)
This live-USB boots Android and many functions are operational
(display, hard keybord, Mouse, Wireless.) I can also install Android
to the CompactFlash and obtain the same results.

So, some functions such as Ethernet (Intel 82874) or Intel HDA audio
do not work but my main concern is the eGalax touchscreen, which
presents the very well known "axis-inversion" symptom: top is bottom
and left is right.

I adapted my own ts.env and ts.conf files and compiled with
BOARD_USES_TSLIB=true. I can see the files in /android/system/etc
(DEBUG boot) or /system/etc (Android) and I can run ts_calibrate which
gives a decent pointercal if I create the data/system/tslib directory
before.

I think one of the points is that BOARD_USES_TSLIB never appears in
the environment and thus the tslib-3 script does nothing. I checked it
by putting traces in tslib-3.
Another point could be that the pathes used at the second stage of the
boot (when tslib-3 is called) are quite different from the pathes
specified in ts.env, as they are prefixed by /android.

I must say I am not at all a Linux expert (used to practice some Unix
in the old days but it is quite far now) and that is is more than
probable that I missed something, so I would be grateful if somebody
puts me back on the right track.

TIA
Remi

[rdg]

Hi,

I answer to my own thread...

I realized that BOARD_USES_TSLIB must be set by the hardware_detect()
script in <platform>_info in order to be used by initrd's init script
and thus by setup_tslib() in 3-tslib.
After having fixed this, ts_calibrate is called at boot time whenever
pointercal is missing.

However, everything behaves like pointercal is not used :-(

I set module_raw to input-raw in ts.conf, because my eGalax device is
not recognized by the galax plugin, due to a very restrictive ID test
(I have the right 0EEF:0001 vendor:device IDs but a different revision
ID!) Could it be an issue?

Any pointer to what could be missing?

Remi

[Chih-Wei Huang]

Hi,
You have done good investigation. Nice!
The fact is, ts calibration is not (yet) supported by
gingerbread-x86 or later version.
The input system was changed a lot since gingerbread,
so we're still unable to bring calibration function to it.
However, you can try to hack it, if you're interesting.

BTW, another fact is, most touchscreen we're testing now
don't need calibration, including eGalax's.

2011/11/19 rdg <grave...@gmail.com>:

> I answer to my own thread...
> I realized that BOARD_USES_TSLIB must be set by the hardware_detect()
> script in <platform>_info in order to be used by initrd's init script
> and thus by setup_tslib() in 3-tslib.
> After having fixed this, ts_calibrate is called at boot time whenever
> pointercal is missing.
>
> However, everything behaves like pointercal is not used :-(
>
> I set module_raw to input-raw in ts.conf, because my eGalax device is
> not recognized by the galax plugin, due to a very restrictive ID test
> (I have the right 0EEF:0001 vendor:device IDs but a different revision
> ID!) Could it be an issue?
>
> Any pointer to what could be missing?

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[William Esser]

Problem solved,

I have found the problem with many of the External USB touchscreens
(Faytech / dlewave / etc)
These screen report back as oeef:0001 version 0100.
The MSB and LSB of the packet are swapped.
I have finished up a patch to usbtouchscreen.c and have finished
testing it.
I am looking to see if it is better to correct this in the
usbtouchscreen.c or the HID interface
so far the usbtouchscreen.c looks this best way.
once this patch is in, the screen response properly (no jumping
posistions) and dose calibrate with
ts_calibrate well.

On first boot up, ts_calibrate runs, and I have a full working 10" and
12" touchscreen
Chih-Wei, I will be posting the patch to you very soon. (need to
complete all my test)

On Nov 19, 6:50 am, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
> Hi,
> You have done good investigation. Nice!
> The fact is, ts calibration is not (yet) supported by
> gingerbread-x86 or later version.
> The input system was changed a lot since gingerbread,
> so we're still unable to bring calibration function to it.
> However, you can try to hack it, if you're interesting.
>
> BTW, another fact is, most touchscreen we're testing now
> don't need calibration, including eGalax's.
>

> 2011/11/19 rdg <gravela...@gmail.com>:

[rdg]

@Chih-Wei

> You have done good investigation. Nice!

Thanks for your encouragement: I just like to understand how things
work, event if it takes me quite a lot of time ;-)

So ts_calibration is not (yet) supported in Gingerbread-x86! Is this
written somewhere or did I miss something (I didn't read all of this
newsgroup)?

I agree with you for the actual calibration needs: my touchscreen
works seamlessly under Windows XP or CE and it is calibrated, with no
need for anything else than the EEPROM-saved parameters. Under Fedora
14, any touch is mapped to the top-left corner of the screen (sounds
like the bug William detected), and under Android-x86 input seems
accurate but with inverted axis.
I'll see what I can do is this concern.

@William
I am not sure your problem is like mine: using the input test
application that ships with Gingerbread-x86, I can see that my screen
input is very smooth and that I can cover the whole surface in a
predictive manner and the *only* point is that top is bottom and left
is right.

Lookint at usbtouchscreen.c code, something bothers me:

/* ignore the HID capable devices, handled by usbhid */
{USB_DEVICE_HID_CLASS(0x0eef, 0x0001), .driver_info =
DEVTYPE_IGNORE},
{USB_DEVICE_HID_CLASS(0x0eef, 0x0002), .driver_info =
DEVTYPE_IGNORE},

Then, in usbtouch_probe():

/* some devices are ignored */
if (id->driver_info == DEVTYPE_IGNORE)
return -ENODEV;

How such a device as EEF:1 could be handled in usbtouchscreen.c?

Anyway, I am interested in your patch, as it might solve my Fedora 14
issue :o)

[William Esser]

I have submitted my patch in the issues section

[rdg]

> I have submitted my patch in the issues section

OK. Understood.
What I can't figure out is the reason of CONFIG_HIDRAW exclusion.

+config TOUCHSCREEN_USB_FAYTECH
+ default n
+ bool "FAYTECH Monitor USB touchscreen Driver" if EXPERT
+ depends on TOUCHSCREEN_USB_COMPOSITE
+ help
+ Special Driver for FAYTECH eGalax 0eff:0001 ver 01xx drivers
+ You must disable HIDRAW to use this driver

Is it really mandatory? What is the issue?
Just asking this because I have another HID that is not an actual
Human Input Device but rather used to poll/drive GPIO. I willl need to
control it through hidraw_get/send_report.

[William Esser]

I have finished the PATCH and it work on both Android-x86 and rowboat
GINGERBREAD
have tested 21 Faytech touchscreen monitors
is listed in issues 452 on the issues section.