[Libdlo] Blanking Support on mimo 740

[Justin Hammond]

Hi,
I didn'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.

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?

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

The only issue I face with touchscreen is it occasionally doesn't  
initilize correctly, but that's a issue for another list. (QWT uses  
Tslib here, I've not dug into that yet)

By the way, the ts_calibrate util didn't work with the E2i  
touchscreen. I had to use the touchscreen calibration functions in QWT  
to generate my /etc/pointercal file.

Justin



On 11-Jan-2010, at 11:37 PM, Hal Glenn <hglenn at 2g-eng.com> wrote:

> Justin, and group.
> Sorry to slightly hijack your topic.
> Interesting about your direct to frame buffer QT program. I'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'd done it before with a PYQT  
> app on a gumstix machine, but it's been a while. I was looking at  
> all the udev stuff last night, but it's still kind of Greek to me.  
> I've upped to to the 2.6.32 kernel so I have the e2i support but  
> don't really know what to do with it yet.
>
> I think if I could get the direct to framebuffer and touch screen  
> support working for my apps, I'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'd also need to fix the horizontal line issue that people are  
> experiencing and I'd be happy to help test and debug where I can!
>
> Thanks
> Hal Glenn
>
> justin at dynam.ac wrote:
>> Hi All,
>> I've managed to get a Mimo 740 running under my FC12 install with no
>> problem using the latest udlfb code from the git Repository.
>>
>> I'm using this setup at the moment with a Embedded version of a QT
>> application, that uses the framebuffer console directly. No problems
>> (mostly) at all there.
>>
>> The only issue I have currently:
>>
>> Blanking Support (via the sysfs path: /sys/class/graphics/fb1/ 
>> blank) is
>> not working at all. I'm trying to write a basic screensaver for my  
>> QT app
>> that will enable blanking, but before I even started on that I  
>> thought I
>> would test out blanking support.
>>
>> I've put some debug statements into the udlfb.c file for the  
>> dlfb_blank
>> function to check its getting called and the dlfb_sync_bulk_msg call
>> returns successfully. This is what I'm getting:
>>
>> usb 1-4.2: dlfb: open /dev/fb1 user=1 count=1
>> usb 1-4.2: dlfb: dlfb_sync_bulk_msg Returned 0
>> usb 1-4.2: dlfb: Blank /dev/fb1 Blank 0
>> usb 1-4.2: dlfb: dlfb_sync_bulk_msg Returned 0
>> usb 1-4.2: dlfb: Blank /dev/fb1 Blank 3
>> usb 1-4.2: dlfb: dlfb_sync_bulk_msg Returned 0
>> usb 1-4.2: dlfb: Blank /dev/fb1 Blank 1
>> usb 1-4.2: dlfb: dlfb_sync_bulk_msg Returned 0
>> usb 1-4.2: dlfb: Blank /dev/fb1 Blank 2
>> usb 1-4.2: dlfb: dlfb_sync_bulk_msg Returned 0
>> usb 1-4.2: dlfb: Blank /dev/fb1 Blank 3
>> usb 1-4.2: dlfb: dlfb_sync_bulk_msg Returned 0
>> usb 1-4.2: dlfb: Blank /dev/fb1 Blank 0
>>
>> But nothing happens to the MIMO. I thought it might have something  
>> to do
>> with a application "opening" on/dev/fb1, but even when closing my  
>> app, I'm
>> still not getting any results.
>>
>> Anything else I can provide to help diagnose this problem?
>>
>> On a side note, and maybe for a latter email, I'm also getting  
>> horizontal
>> artifacts on the screen after several hours of operations. Reading  
>> the
>> archives, I saw someone else post on this, and there was a thought  
>> there
>> was a race condition on the memmap. This is very reproducible for me
>> (takes about 1 hour though) so if I can provide further info to  
>> help debug
>> that, I'm willing to take on the challenge!
>>
>> One last question and I'm not sure if its even supported on these
>> displaylink devices, but can we implement software backlight  
>> control? If
>> someone knows the command/registers, I'm more than willing to have  
>> a stab
>> at implementing it (my first venture into Kernel Programming  
>> though...)
>>
>> Cheers
>>
>> Justin
>>
>>
>> _______________________________________________
>> Libdlo mailing list
>> Libdlo at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/libdlo
>>