Bloody Linux
I have recently warmed to Linux.
I then immediately went off it again.
I tried to install a touchscreen. According to the webosphere it was going to be a relatively easy job. Sure it involved manually editting a few config files here and there, but no worries there.
Sadly it doesn't work.
Partially because the touchscreen isn't the model that has working Linux drivers, its a variant, so you have to download slightly different drivers for it, that have the same name, and there's no version info.
Partially because it took me a while to figure out which configuration file I was editting, (no, not XF86Config, \etc\X11\xorg.conf don't you know).
But mostly because the bloody board has jumpers on it that switch it between Windows compatability mode and Linux compatability mode, and I don't have the required diamond-edged drill bit, or ridiculously tiny alun keys that I need to break the bloody case open and remove said jumper.
A colleague, many moons ago, did get the touch screen working with the evil windows jumper in place. He doesn't remember how, and I can't figure it out, so after three days I'm doing something that I've never done before.... I'm giving up.
For an engineer to give up it typically involves threats to his/her family and an automatic weapon. Sadly, I simply can't afford to spend any more time on it.
This makes me sad and angry.
I've written an email to the manufacturers of the robot concerned explaining that the screen simply isn't responding to configuration requests, (annoyingly it is sending out info when you touch it, but I have no way of translating that info into a mouse pointer.) I'm actually begninning to think it would be easier to reverse engineer the protocol and write a decent driver for it myself.
I then immediately went off it again.
I tried to install a touchscreen. According to the webosphere it was going to be a relatively easy job. Sure it involved manually editting a few config files here and there, but no worries there.
Sadly it doesn't work.
Partially because the touchscreen isn't the model that has working Linux drivers, its a variant, so you have to download slightly different drivers for it, that have the same name, and there's no version info.
Partially because it took me a while to figure out which configuration file I was editting, (no, not XF86Config, \etc\X11\xorg.conf don't you know).
But mostly because the bloody board has jumpers on it that switch it between Windows compatability mode and Linux compatability mode, and I don't have the required diamond-edged drill bit, or ridiculously tiny alun keys that I need to break the bloody case open and remove said jumper.
A colleague, many moons ago, did get the touch screen working with the evil windows jumper in place. He doesn't remember how, and I can't figure it out, so after three days I'm doing something that I've never done before.... I'm giving up.
For an engineer to give up it typically involves threats to his/her family and an automatic weapon. Sadly, I simply can't afford to spend any more time on it.
This makes me sad and angry.
I've written an email to the manufacturers of the robot concerned explaining that the screen simply isn't responding to configuration requests, (annoyingly it is sending out info when you touch it, but I have no way of translating that info into a mouse pointer.) I'm actually begninning to think it would be easier to reverse engineer the protocol and write a decent driver for it myself.

5 Comments:
Exactly how tiny are the Allen keys involved? Is it definitely a hex fitting and not a Torx?
Maplin sell a screwdriver bit set that has pretty small sizes of both, it may be worthwhile measuring the diameter of the hole and seeing if you can find a bit that'll fit:
http://www.maplin.co.uk/Module.aspx?TabID=1&ModuleNo=3913&doy=21m3
http://www.maplin.co.uk/Module.aspx?TabID=1&ModuleNo=11520&doy=21m3
http://www.maplin.co.uk/Module.aspx?TabID=1&ModuleNo=34154&doy=21m3
I know what you mean about engineers not wanting to give up, I refuse to be beaten by any job, until I get streessed and throw it across the room.
OK so a few things:
* XF86Config?? WTF? Is this 1999?! No! Welcome to Xorg!
* Slashes /go/this/way in Linux
* I expect (like Simon) that it is indeed a Torx thing - I have a size 10 if it's any use :)
So out of (non) professional interest:
* What did you have to add into Xorg.conf
* What do you see in /var/log/Xorg.0.log
* What version/distro of Linux are you using?
Out of cynicism I have to ask:
* Why are you trying to attach a touch screen? It obviously worked fine before.
love and hugs
jonh (one of those Linux loving types who actually enjoys this kind of crap)
Ok, ok. So this story needs an update...
1) The torx would be great, if the previous owner hadn't worn the screw heads off on most of them by using the wrong size!
2) I was looking at XF86Config because the previous owner also installed an antiquated version of Debian that was still using XF86, so when I updated, the config files moved!
3) It turns out that all the modifications that I was making were actually spot on. I'll publish the details later, but the upshot was creating a new pointing device using the appropriate module.
4) It turns out that the only way that you can get this bloody thing working is to comment out all references to receiving feedback from the screen and then use the recompiled module. The reason... they cut the wire that links the screen back to the computer, without mentioning it in the documentation.
I may or may not be able to access where they cut it.
5) The log file basically says that the device isn't responding to the ID message that it sends out. Which I had put down to a config error, but turns out is down to the bloody connection simply not being there.
6) The reason it stopped working is because I updated the Debian distro to one that would let me do certain GUI things that the XF86 wouldn't let me do. Sadly the update process lost the original configuration info :(
I'm shelving this project as other priorities have taken hold.
boB - if the screw heads are knackered, the easiest way to deal with it is drill them out. Then, fix what you need and use problem solver number one. Gaffer tape.
I'm hoping that the missing wire was disconnected by simply not passing the connection from one end of the terminal block to the other. I have access to the terminal block in question so I should be able to reconnect it. Failing that I'll have to download the libraries that I need to recompile my own version of the module so I can remove the need for ID requests. The manufacturer modified version isn't supported by xorg, it needs XF86!
Failing that, you can guarantee a blue-tac/gaffa tape orientated solution.
I recently constructed a sensor housing for a quantum tunnelling pill using sellotape, kitchen foil and blue-tac. It was a beautiful thing to behold!
Post a Comment
<< Home