Can you guys try this image:
http://indashpc.org/downloads/softwa....3-flipped.iso
Printable View
Can you guys try this image:
http://indashpc.org/downloads/softwa....3-flipped.iso
Hi
Seems to work.
THX
Chaos
A question on this. You mentioned somewhere that you would be releasing a "generic hardware" version of the pycar iso, any timescales on this?
I tried to boot this CD on my laptop, but it doesn't work presumably because of EPIA specific framebuffer drivers etc.
Be nice to try it out for real. (sold my EPIA months ago)
I can release such a thing, but still you have to provide your own kernel with all the drivers included( sound, usb, ide ).
Ever tried to run windows without installing drivers ?
How about enabling loadable module support (didn't check if it already was) so people can compile modules for any hardware they need?Quote:
Originally Posted by jbors
Well, I enabled modules support in my distro but the module has to be in initrd file, so you have to recompile the initrd from scratch which may be tricky. And then write a script to initialize the right set of modules.
I would say compiling kernel with drivers in it would be the easiest way for you.
jbors:
Perhaps I can shed some light on this problem. The 4 wire touchscreen interface used by both the lilliput and the xenarc expect one axis on the left two pins and one axis on the right two -- this is on the connector coming off of the touch overlay to the touch controller. Of course the plug is not polarized and can plug in either way.. so depending on the specific overlay and the specific way the person on the assembly line folded the cable and plugged it in.. they are sometimes different from one screen to the next. The egalax windows driver does not make any assumptions about which axis is which and determines it from the calibration points.
I discovered this when I swapped out a touch overlay on the (better) lilliput LCD panel with the (better) xenarc overaly. The way the ribbon cables were configured meant that I had a swapped X and Y when I set the screen back up.
If you ended up writing your own driver for the TS, you might just look into doing a similar method to detect orientation.. instead of assuming X and Y, just do a 4 points calibration and determine which axis is which...
Good to know that. I'll see if I can come up with the configurable way. Right now all scaling and things happens @ linux input level so I have no control for that.