Find the answer to your Linux question:
Results 1 to 5 of 5
Hi there everyone, I am a newbie in the world of X11 and I am trying to find out the simplest and most efficient solution for this rather unique issue ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Mar 2009
    Posts
    5

    Question Hi there, question on Touch Screen and the X11 Server


    Hi there everyone,

    I am a newbie in the world of X11 and I am trying to find out the simplest and most efficient solution for this rather unique issue I am addressing.

    Basically, this embeded system I am working on uses a kdrive X11 (KDrive - Wikipedia, the free encyclopedia) that is integrated into a 2.6.18 Debian Linux kernel. This system does not use the xorg.conf for configuration and does not seem to have an active X server running. The embedded box has an HDMI output for display and has USB and serial ports.

    So this is where my issue resides. I am trying to get several touch screen monitors to work with this embedded box.

    I am looking into screens made by vendors such as 3M and Elo , and the way their Linux drivers work is to have an X11 touch-screen module ( usually .o file placed under /usr/lib/xorg/modules/input/ ) and adding an InputDevice entry for the touchscreen in the xorg.conf file. An example of what I describe for the touch driver installation process is right here for a 3M touch screen : Xorg Touchscreen Driver

    Now, if my kdrive X11 does not even use an xorg.conf file or an active X11 server, I am trying to find a workaround solution, and here are two that I am considering :

    (1) Ask the firmware developer for each touch screen vendor to build a special driver that will call the XTestFake functions from the X11/extensions/Xtest.h ( xtestfakemotionevent(3) - Linux man page ) to simulate fake mouse events. I have experimented this already with one particular touch screen where I made a special driver that would read in the touch-screen data via serial and then call the specific XTestFake functions to move the mouse pointer on-screen. The problem with this approach is that I would have to consult the firmware developer for each touch screen I plan to support for my system, since I wouldn't want to write the driver myself for ALL the screens.

    (2) Allow each touch screen vendor to use their original drivers and then on my end, I can build some form of a middleware that can accept the original drivers and still be able to use XTestFake to emulate the necessary mouse events. I was wondering if a good suggestion would be to use Xfvb ? Will it complicate the fact that this system already uses kdrive?

    Please enlighten a fellow X11 newb here. I just want to carefully consider my options before going too far down either path

    Thanks!

    I.S.

  2. #2
    Linux Newbie
    Join Date
    Feb 2009
    Location
    Third ring of Pergatory
    Posts
    199
    A Kdrivesystem comiles at run time from code, not a configuration file. You'd have to edit the code, no mean trick. Your real problem though isn't the video, it's the mouse (the touches on your touch screen). It's got very limited support for pointer devices.

    If you gave the poor thing a usb hard drive--or maybe even a fat stick of mem, you might get it to spawn an X server, and it's a cakewalk from there.

  3. #3
    Just Joined!
    Join Date
    Mar 2009
    Posts
    5
    Quote Originally Posted by dijetlo View Post
    A Kdrivesystem comiles at run time from code, not a configuration file. You'd have to edit the code, no mean trick. Your real problem though isn't the video, it's the mouse (the touches on your touch screen). It's got very limited support for pointer devices.

    If you gave the poor thing a usb hard drive--or maybe even a fat stick of mem, you might get it to spawn an X server, and it's a cakewalk from there.
    Hi there, thanks for the reply. So you are pointing out that it will be rather difficult to make an X Windows module work with Kdrive then? Would you recommend any documentation on compiling Kdrive from scratch for this kind of case?

    This embedded device actually runs off an SD card with 4 gigs and 1 gig of RAM. I believe it should be able to start up the X server then?

    Thanks for the advice
    IS

  4. #4
    Linux Newbie
    Join Date
    Feb 2009
    Location
    Third ring of Pergatory
    Posts
    199
    So you are pointing out that it will be rather difficult to make an X Windows module work with Kdrive then?
    Kdrive was written for machines that lacked the rescources to spawn X-windows. If the guy who wrote it was smart (and he was), he stripped the access points for the services and resources out of the kernel so even if you reinvented the wheel and wrote an X-server into K-drive, the kernel likely would refuse to execute it unless you rewrote that too( in which case congratulations, you and Linus Torvalds have a lot to talk about)
    Would you recommend any documentation on compiling Kdrive from scratch for this kind of case?
    I wouldn't even attempt it. On a cost benefit analysis your going to have to deliver some serious benefit to cover the man hour costs of building your own kernel
    This embedded device actually runs off an SD card with 4 gigs and 1 gig of RAM. I believe it should be able to start up the X server then?
    You'll need a new kernel to load the x-window modules.
    The problem here is you can't frankenstein these boxes and dedicate them to your x-windowing project. They are doing something now, something someone thinks important. The shortest path to what you want is to hack up a stripped down kernel and load the minimal version of slack on the embed, but whatever it was doing...probably not going to do it now, not unless you configure slack to do what Kdrive used to do.You have four gig, there are some really small distros of GNU/Linux that would find that roomy. What service do the imbeds perform now, can it be configured to run on the larger kernel? What kind of hardware is it?

  5. #5
    Just Joined!
    Join Date
    Mar 2009
    Posts
    5
    Quote Originally Posted by dijetlo View Post
    Kdrive was written for machines that lacked the rescources to spawn X-windows. If the guy who wrote it was smart (and he was), he stripped the access points for the services and resources out of the kernel so even if you reinvented the wheel and wrote an X-server into K-drive, the kernel likely would refuse to execute it unless you rewrote that too( in which case congratulations, you and Linus Torvalds have a lot to talk about)

    I wouldn't even attempt it. On a cost benefit analysis your going to have to deliver some serious benefit to cover the man hour costs of building your own kernel

    You'll need a new kernel to load the x-window modules.
    The problem here is you can't frankenstein these boxes and dedicate them to your x-windowing project. They are doing something now, something someone thinks important. The shortest path to what you want is to hack up a stripped down kernel and load the minimal version of slack on the embed, but whatever it was doing...probably not going to do it now, not unless you configure slack to do what Kdrive used to do.You have four gig, there are some really small distros of GNU/Linux that would find that roomy. What service do the imbeds perform now, can it be configured to run on the larger kernel? What kind of hardware is it?
    I see. In this case, I am considering switching to a normal (but stripped down) and more modular Xorg server instead of Kdrive, since this hardware should have enough resources to run it. Will this be easier to configure/build then instead of Kdrive?

    I am also in the process of using a new kernel version ( 2.6.18.8 ) on this box and this might be a good time to change the X server from Kdrive as well.

    As long as a touch screen (1) gets recognized by the kernel as an input device and (2) has X11 modules that will work with the Xorg server as a mouse InputDevice, that's basically all I need.

    Thanks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •