[Qt-embedded-interest] subscribe
Andy
andy at midoriyasz.com
Mon Jul 6 03:22:24 CEST 2009
----- Original Message -----
From: <qt-embedded-interest-request at trolltech.com>
To: <qt-embedded-interest at trolltech.com>
Sent: Thursday, July 02, 2009 2:39 PM
Subject: Qt-embedded-interest Digest, Vol 15, Issue 3
> Send Qt-embedded-interest mailing list submissions to
> qt-embedded-interest at trolltech.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.trolltech.com/mailman/listinfo/qt-embedded-interest
> or, via email, send a message with subject or body 'help' to
> qt-embedded-interest-request at trolltech.com
>
> You can reach the person managing the list at
> qt-embedded-interest-owner at trolltech.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Qt-embedded-interest digest..."
>
>
> Today's Topics:
>
> 1. FW: Double Buffer Graphics Driver (Bryce Salmi)
> 2. Re: long-term delay for QDir::entryList(), QDir::count() for
> directory located on USB stick (Markus Franke)
> 3. Antwort: Re: [Qt-interest] long-term delay for
> QDir::entryList(), QDir::count() for directory located on USB
> stick (Markus Franke)
> 4. Re: FW: Double Buffer Graphics Driver (Tom Cooksey)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 1 Jul 2009 06:07:36 -0700
> From: "Bryce Salmi" <Bryce.Salmi at zoran.com>
> Subject: [Qt-embedded-interest] FW: Double Buffer Graphics Driver
> To: "qt embedded list" <qt-embedded-interest at trolltech.com>
> Message-ID:
> <C9F0FF684868EC498981CAF8B381321203741AED at zcoex.ZCO.Zoran.COM>
> Content-Type: text/plain; charset="us-ascii"
>
> Tom,
> Thank you for the reply and I was hoping that wouldn't be the case.
> Well, in this case it does look like I will have to write the driver as
> you suggested which makes sense. However, on the Qt documentation for
> the accelerated graphics driver the example uses SVGAlibs which I do not
> think applies to my board. Is there another example of one that does
> not use SVGAlibs that would be good to at least see another
> implementation of the custom driver. Maybe there are some other ideas
> you may have or at least directions to point me in? Thank you for your
> time.
>
>
>
>
> Sincerely,
>
> Bryce Salmi
>
> -----Original Message-----
> From: qt-embedded-interest-bounces at trolltech.com
> [mailto:qt-embedded-interest-bounces at trolltech.com] On Behalf Of Tom
> Cooksey
> Sent: Wednesday, July 01, 2009 2:55 AM
> To: qt-embedded-interest at trolltech.com
> Subject: Re: [Qt-embedded-interest] Double Buffer Graphics Driver
>
>> Qt List,
>> I am at a point where I am trying to get the Double Buffer
>> Graphics Driver working. I have been able to implement the driver
>> and get it to at least be recognized by the program trying to be
>> run. However there is no display on the LCD from the program. I
>> know the programs run when I use the VNC display. Here is what I
>> did: Built the plug-in (all four files located either at
>> QTDIR/examples/qws/dbscreen or on the link above) by invoking qmake
>> without the -project option since there is already a .pro file, I
>> then simply ran make resulting in the output file which was named
>> "libdbscreen.so". One way to use the plug-in was to create a
>> directory in the application directory, so in my case I created
>> analogclock/gfxdrivers and placed libdbscreen.so into it (make sure
>> permissions are set). At this point I could simply run the command
>> in the application root directory:
>>
>> ./analogclock -qws -display dbscreen
>>
>> The resulting output was "blit_16(): Image format 0 not supported!"
>> continuously being printed on the command line (once per second...
>> maybe from the clock actually trying to update the area that
>> changed?). There were no LCD changes but at least the driver was
>> recognized and could be run.
>>
>> I would like to figure this out and think that the blit could be
>> manually set? I simply need to copy over the buffer in memory to
>> the /dev/fbo which I have accessed before in C. There is no mmap
>> support on my board (ARM) so the frame buffer test doesn't work... I
>> was hoping that this would be a way to work around mmap problem.
>
> The dbscreen driver still uses the regular LinuxFBScreen, which itself
> uses mmap. I think you need to take a look at the LinuxFBScreen class,
> in particular initDevice & connect and write your own screen driver
> which inherits QLinuxFBScreen and which re-implements initDevice,
> connect & blit.
>
>
> Cheers,
>
> Tom
>
>
> _______________________________________________
> Qt-embedded-interest mailing list
> Qt-embedded-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-embedded-interest
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 1 Jul 2009 15:29:37 +0200
> From: Markus Franke <Franke.M at sebakmt.com>
> Subject: Re: [Qt-embedded-interest] long-term delay for
> QDir::entryList(), QDir::count() for directory located on USB stick
> To: qt-interest at trolltech.com, qt-embedded-interest at trolltech.com
> Message-ID:
> <OF69609DF3.F38CDB4F-ONC12575E6.00498F13-C12575E6.004A2076 at sebakmt.com>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I just figured out that the problem only occurs in case the cluster size
> of the FAT32 filesystem on the 4GByte USB stick is 4 KByte.
> If I change the cluster size to 32 KByte everything works fine.
> By the way, same applies for USB sticks from other vendors.
>
> Any comments on this?
>
> Mit freundlichen Gr??en / Best regards
>
> Markus Franke
> Entwicklung/ Development
>
> SebaKMT
> Hagenuk KMT Kabelmesstechnik GmbH
> R?deraue 41
> 01471 Radeburg / Germany
> Reg.Gericht (01067 Dresden) HRB 12567
> Gesch?ftsf.: Dr. Max Iann
>
> Phone +49 (0)35208 84 29142
> Fax +49 (0)35208 84 29249
>
> e-mail: franke.m at sebaKMT.com
> web: http//www.sebaKMT.com
>
>> Dear all,
>
>> this message has already been on qt-interest but I just figured out that
>
>> it just applies (as far as I know) for Qt Embedded 4.5.0.
>>
>> I am observing long runtimes (around 50 seconds) for the functions
>> QDir::entryList() and QDir::count() when the directory is located on an
>> USB stick with VFAT filesystem. The long-term delay only occurs once
> after
>> the USB stick has been mounted for the first time. Subsequent calls
>> complete within a few seconds (one or two) which is alright for me.
>>
>> Here is some sample code which doesn't work for me:
>>
>> ---snip---
>> QDir directory("/USB");
>> directory.setNameFilters(QStringList("*.img"));
>> directory.setFilter(QDir::NoDotAndDotDot | QDir::NoSymLinks |
>> QDir::Files);
>>
>> // This takes about 50 seconds when called for the first time
>> qDebug("count = %d", directory.count());
>> ---snap---
>>
>> The USB stick get's recognized as a USB 1.1 device and I am on a Linux
> 2.6
>> system. I am using Qt Embedded 4.5.0
>>
>> Mit freundlichen Gr??en / Best regards
>>
>> Markus Franke
>> Entwicklung/ Development
>>
>> SebaKMT
>> Hagenuk KMT Kabelmesstechnik GmbH
>> R?deraue 41
>> 01471 Radeburg / Germany
>> Reg.Gericht (01067 Dresden) HRB 12567
>> Gesch?ftsf.: Dr. Max Iann
>>
>> Phone +49 (0)35208 84 29142
>> Fax +49 (0)35208 84 29249
>>
>> e-mail: franke.m at sebaKMT.com
>> web: http//www.sebaKMT.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.trolltech.com/pipermail/qt-embedded-interest/attachments/20090701/156dd707/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Wed, 1 Jul 2009 15:56:20 +0200
> From: Markus Franke <Franke.M at sebakmt.com>
> Subject: [Qt-embedded-interest] Antwort: Re: [Qt-interest] long-term
> delay for QDir::entryList(), QDir::count() for directory located on
> USB stick
> To: Sean Harmer <sean.harmer at maps-technology.com>
> Cc: qt-embedded-interest at trolltech.com
> Message-ID:
> <OFE396B94A.9BAC3035-ONC12575E6.004BA05A-C12575E6.004C92C8 at sebakmt.com>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> qt-interest-bounces at trolltech.com schrieb am 01.07.2009 15:36:49:
>
>> First off, have you isolated the problem to be in the linux kernel's
> driver or
>> the Qt code or your code?
>
> Well, I thought I isolated the problem. If I plug-in the device, it get's
> properly recognized and mounted by my hotplugging script.
>
>> You can test to see if it is a kernel level problem by simply doing an
> ls in
>> your usb stick's filesystem and timing that. If that takes a long time
> the
>> first time that you run it, then it is a kernel/filesystem/hw problem.
>
> Strange. If I type an 'ls' command for the first time after plugging in
> the USB stick it is very fast. However, if I issue a 'df' command it's
> taking a very long time.
>
> Seems like you were right and it is a kernel level problem.
>
> Although it doesn't belong to this list: Does anybody have a suggestion
> how to fix this problem?
>
>
> Mit freundlichen Gr??en / Best regards
>
> Markus Franke
> Entwicklung/ Development
>
> SebaKMT
> Hagenuk KMT Kabelmesstechnik GmbH
> R?deraue 41
> 01471 Radeburg / Germany
> Reg.Gericht (01067 Dresden) HRB 12567
> Gesch?ftsf.: Dr. Max Iann
>
> Phone +49 (0)35208 84 29142
> Fax +49 (0)35208 84 29249
>
> e-mail: franke.m at sebaKMT.com
> web: http//www.sebaKMT.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.trolltech.com/pipermail/qt-embedded-interest/attachments/20090701/a87037af/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Thu, 2 Jul 2009 08:37:51 +0200
> From: Tom Cooksey <thomas.cooksey at nokia.com>
> Subject: Re: [Qt-embedded-interest] FW: Double Buffer Graphics Driver
> To: qt-embedded-interest at trolltech.com
> Message-ID: <200907020837.52172.thomas.cooksey at nokia.com>
> Content-Type: Text/Plain; charset="us-ascii"
>
>>> > I am at a point where I am trying to get the Double Buffer
>>> > Graphics Driver working. I have been able to implement the
>>> > driver and get it to at least be recognized by the program
>>> > trying to be run. However there is no display on the LCD from
>>> > the program. I know the programs run when I use the VNC
>>> > display. Here is what I did: Built the plug-in (all four files
>>> > located either at QTDIR/examples/qws/dbscreen or on the link
>>> > above) by invoking qmake without the -project option since there
>>> > is already a .pro file, I then simply ran make resulting in the
>>> > output file which was named "libdbscreen.so". One way to use
>>> > the plug-in was to create a directory in the application
>>> > directory, so in my case I created analogclock/gfxdrivers and
>>> > placed libdbscreen.so into it (make sure permissions are set).
>>> > At this point I could simply run the command in the application
>>> > root directory:
>>> >
>>> > ./analogclock -qws -display dbscreen
>>> >
>>> > The resulting output was "blit_16(): Image format 0 not
>>> > supported!" continuously being printed on the command line (once
>>> > per second... maybe from the clock actually trying to update the
>>> > area that changed?). There were no LCD changes but at least the
>>> > driver was recognized and could be run.
>>> >
>>> > I would like to figure this out and think that the blit could be
>>> > manually set? I simply need to copy over the buffer in memory
>>> > to the /dev/fbo which I have accessed before in C. There is no
>>> > mmap support on my board (ARM) so the frame buffer test doesn't
>>> > work... I was hoping that this would be a way to work around
>>> > mmap problem.
>>>
>>> The dbscreen driver still uses the regular LinuxFBScreen, which
>>> itself uses mmap. I think you need to take a look at the
>>> LinuxFBScreen class, in particular initDevice & connect and write
>>> your own screen driver which inherits QLinuxFBScreen and which
>>> re-implements initDevice, connect & blit.
>>>
>> Thank you for the reply and I was hoping that wouldn't be the
>> case. Well, in this case it does look like I will have to write the
>> driver as you suggested which makes sense. However, on the Qt
>> documentation for the accelerated graphics driver the example uses
>> SVGAlibs which I do not think applies to my board. Is there
>> another example of one that does not use SVGAlibs that would be
>> good to at least see another implementation of the custom driver.
>> Maybe there are some other ideas you may have or at least
>> directions to point me in? Thank you for your time.
>
> I don't know to any simple examples you could use. I think actually
> you just need to create a new driver which inherits QScreen. As you
> can't get a pointer to your graphics memory, the driver will need a
> "shadow" buffer instead (So it can read data for blend operations).
> You can create a QImage for that in initDevice, and set the screen's
> addr pointer to the image's bits(). Then you just need to re-implement
> blit() to copy the blended data to your real framebuffer using an
> ioctl or whatever.
>
> Hope that helps?
>
>
> Cheers,
>
> Tom
>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Qt-embedded-interest mailing list
> Qt-embedded-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-embedded-interest
>
>
> End of Qt-embedded-interest Digest, Vol 15, Issue 3
> ***************************************************
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 4204 (20090701) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
More information about the Qt-embedded-interest
mailing list