Justin, et al.<br><br>In the past I&#39;ve built pyQT for QT embedded running on an ARM, using QWT to the linuxFB. It worked well and would seem to be a good solution for my app. I spent a bunch of time last night looking over it all and I did not want to recompile my ubuntu pyqt stuff to enable the direct to linuxfb support. So I ended up just starting up an X server and working on getting a basic pyqt app running on it.<br>
<br>Today I learned about udev and modified the scrips that were so generously provided by Bernie and the list to make a seat for each of my mimo 720 monitors. Next onto getting automated startup for X and my apps and getting the touch screen calibrated correctly, it needs a slight tweak and i just haven&#39;t figured out how to do it yet.<br>
<br>Thanks everyone for the historical posts, development, and the wiki!<br>Hal<br><br><div class="gmail_quote">On Mon, Jan 11, 2010 at 10:48 AM, Justin Hammond <span dir="ltr">&lt;<a href="mailto:justin@dynam.ac">justin@dynam.ac</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>
I didn&#39;t have to touch the Udev scripts at all. Initially I had my QT prog set to open a /dev/input6 but found that changed devices on reboot. In the end I had it open a /dev/by-id/* device instead.<br>
<br>
You might be able to map the by-id touchscreen device to a framebuffer entry (but there was no by-id entries for framebuffers so might have to dig into udev there if they change on boot) or parse some of the /sys/graphics/ entries?<br>

<br>
Running 10 X.org sessions seems like a big waste of resources! The QT embedded (QWT) stuff is 90% identical to standard QT, but not sure if pyQT supports it<br>
<br>
The only issue I face with touchscreen is it occasionally doesn&#39;t initilize correctly, but that&#39;s a issue for another list. (QWT uses Tslib here, I&#39;ve not dug into that yet)<br>
<br>
By the way, the ts_calibrate util didn&#39;t work with the E2i touchscreen. I had to use the touchscreen calibration functions in QWT to generate my /etc/pointercal file.<br>
<br>
Justin<div><div></div><div class="h5"><br>
<br>
<br>
<br>
On 11-Jan-2010, at 11:37 PM, Hal Glenn &lt;<a href="mailto:hglenn@2g-eng.com" target="_blank">hglenn@2g-eng.com</a>&gt; wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Justin, and group.<br>
Sorry to slightly hijack your topic.<br>
Interesting about your direct to frame buffer QT program. I&#39;m in the processors of converting a large 10 monitor (MIMO 720)  PYQT application over to Linux from windows. I had thought about going the direct to frame buffer route but I did not know how I was going to get all the touch screens working. I&#39;d done it before with a PYQT app on a gumstix machine, but it&#39;s been a while. I was looking at all the udev stuff last night, but it&#39;s still kind of Greek to me. I&#39;ve upped to to the 2.6.32 kernel so I have the e2i support but don&#39;t really know what to do with it yet.<br>

<br>
I think if I could get the direct to framebuffer and touch screen support working for my apps, I&#39;d be able to have a udev script that fires up each PYQT aplication on the correct frame buffer as the devices are attached correct? Does this sound legitimate? It would keep me from having to fire up 10 X servers, which I think would be good! I&#39;d also need to fix the horizontal line issue that people are experiencing and I&#39;d be happy to help test and debug where I can!<br>

<br>
Thanks<br>
Hal Glenn<br>
<br>
<a href="mailto:justin@dynam.ac" target="_blank">justin@dynam.ac</a> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi All,<br>
I&#39;ve managed to get a Mimo 740 running under my FC12 install with no<br>
problem using the latest udlfb code from the git Repository.<br>
<br>
I&#39;m using this setup at the moment with a Embedded version of a QT<br>
application, that uses the framebuffer console directly. No problems<br>
(mostly) at all there.<br>
<br>
The only issue I have currently:<br>
<br>
Blanking Support (via the sysfs path: /sys/class/graphics/fb1/blank) is<br>
not working at all. I&#39;m trying to write a basic screensaver for my QT app<br>
that will enable blanking, but before I even started on that I thought I<br>
would test out blanking support.<br>
<br>
I&#39;ve put some debug statements into the udlfb.c file for the dlfb_blank<br>
function to check its getting called and the dlfb_sync_bulk_msg call<br>
returns successfully. This is what I&#39;m getting:<br>
<br>
usb 1-4.2: dlfb: open /dev/fb1 user=1 count=1<br>
usb 1-4.2: dlfb: dlfb_sync_bulk_msg Returned 0<br>
usb 1-4.2: dlfb: Blank /dev/fb1 Blank 0<br>
usb 1-4.2: dlfb: dlfb_sync_bulk_msg Returned 0<br>
usb 1-4.2: dlfb: Blank /dev/fb1 Blank 3<br>
usb 1-4.2: dlfb: dlfb_sync_bulk_msg Returned 0<br>
usb 1-4.2: dlfb: Blank /dev/fb1 Blank 1<br>
usb 1-4.2: dlfb: dlfb_sync_bulk_msg Returned 0<br>
usb 1-4.2: dlfb: Blank /dev/fb1 Blank 2<br>
usb 1-4.2: dlfb: dlfb_sync_bulk_msg Returned 0<br>
usb 1-4.2: dlfb: Blank /dev/fb1 Blank 3<br>
usb 1-4.2: dlfb: dlfb_sync_bulk_msg Returned 0<br>
usb 1-4.2: dlfb: Blank /dev/fb1 Blank 0<br>
<br>
But nothing happens to the MIMO. I thought it might have something to do<br>
with a application &quot;opening&quot; on/dev/fb1, but even when closing my app, I&#39;m<br>
still not getting any results.<br>
<br>
Anything else I can provide to help diagnose this problem?<br>
<br>
On a side note, and maybe for a latter email, I&#39;m also getting horizontal<br>
artifacts on the screen after several hours of operations. Reading the<br>
archives, I saw someone else post on this, and there was a thought there<br>
was a race condition on the memmap. This is very reproducible for me<br>
(takes about 1 hour though) so if I can provide further info to help debug<br>
that, I&#39;m willing to take on the challenge!<br>
<br>
One last question and I&#39;m not sure if its even supported on these<br>
displaylink devices, but can we implement software backlight control? If<br>
someone knows the command/registers, I&#39;m more than willing to have a stab<br>
at implementing it (my first venture into Kernel Programming though...)<br>
<br>
Cheers<br>
<br>
Justin<br>
<br>
<br>
_______________________________________________<br>
Libdlo mailing list<br>
<a href="mailto:Libdlo@lists.freedesktop.org" target="_blank">Libdlo@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/libdlo" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libdlo</a><br>
<br>
</blockquote></blockquote>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Hal Glenn<br>2G Engineering LLC<br>608-628-8941<br>