From: Bryan Bui-T. <bb...@sp...> - 2008-09-08 18:10:14
|
Has anyone used the gumstix with a 16bit display (RGB 565) and QT4? I got it all working, but the images and gradients seem to be displayed in 8-bits/pixel. I have recompiled QT4 with a depth of 16 bits and still the same results. Gradients are displayed as solid colors and the window styles are very ugly. Thanks in advance. Regards, Bryan |
From: Tom C. <tho...@tr...> - 2008-09-09 06:32:57
|
On Monday 08 September 2008 20:10:11 Bryan Bui-Tuong wrote: > Has anyone used the gumstix with a 16bit display (RGB 565) and QT4? I got > it all working, but the images and gradients seem to be displayed in > 8-bits/pixel. I have recompiled QT4 with a depth of 16 bits and still the > same results. Gradients are displayed as solid colors and the window > styles are very ugly. Thanks in advance. Our tests on 16-bit Gumstix look ok... What version of Qt for Embedded Linux/Qtopia Core are you running? Are you using pre-build OE packages, compiling packages with OE or compiling yourself outside of OE? Could you also post a simple test case which re-produces the problem? Cheers, Tom |
From: Bryan Bui-T. <bb...@sp...> - 2008-09-09 16:47:40
|
Hi Tom, I am using Buildroot and not OE, but my kernel is 2.6.21gum #3 and uBoot 1.2.0. I am using Qtopia-Core 4.2.2 and have tested the framebuffer, with gradients displaying fine and verified that it is in 16-bit mode. As for a simple test case, I create a window and the problem can be seen in the title bar. It is displayed as two solid colors, blue on the top half and teal on the bottom half (not very pretty). I have changed the configuration file for Buildroot to build QT-core 4.2.2 with only 16-bit depth and still the same results. As for hardware, I have grounded the Blue and Red LSB's. Providing the full range of colors (RGB 565). Thanks in advance. Regards, Bryan > -----Original Message----- > From: gum...@li... [mailto:gumstix- > use...@li...] On Behalf Of Tom Cooksey > Sent: Monday, September 08, 2008 11:33 PM > To: gum...@li... > Subject: Re: [Gumstix-users] Gumstix + QT4 @ 16bpp > > On Monday 08 September 2008 20:10:11 Bryan Bui-Tuong wrote: > > Has anyone used the gumstix with a 16bit display (RGB 565) and QT4? > I got > > it all working, but the images and gradients seem to be displayed in > > 8-bits/pixel. I have recompiled QT4 with a depth of 16 bits and > still the > > same results. Gradients are displayed as solid colors and the window > > styles are very ugly. Thanks in advance. > > Our tests on 16-bit Gumstix look ok... What version of Qt for Embedded > Linux/Qtopia Core > are you running? Are you using pre-build OE packages, compiling > packages with OE or > compiling yourself outside of OE? > > Could you also post a simple test case which re-produces the problem? > > > Cheers, > > Tom > > > ----------------------------------------------------------------------- > -- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Tom C. <tho...@tr...> - 2008-09-10 07:51:05
|
On Tuesday 09 September 2008 18:47:37 Bryan Bui-Tuong wrote: > Hi Tom, > > I am using Buildroot and not OE, but my kernel is 2.6.21gum #3 and uBoot > 1.2.0. I am using Qtopia-Core 4.2.2 and have tested the framebuffer, with > gradients displaying fine and verified that it is in 16-bit mode. As for a > simple test case, I create a window and the problem can be seen in the > title bar. It is displayed as two solid colors, blue on the top half and > teal on the bottom half (not very pretty). > > I have changed the configuration file for Buildroot to build QT-core 4.2.2 > with only 16-bit depth and still the same results. That's probably your problem. I don't think 4.2.2 calculated gradiants in their native pixel format - it would use RGB888 and then convert to RGB565. Try re-enabling the other color depths. Or you could try a newer version, say 4.4.1 > As for hardware, I have grounded the Blue and Red LSB's. Providing the > full range of colors (RGB 565). Is that right? I thought you tie the LSB to the next-LSB? If you simply ground them, white will actually be a very, very bright green: RRRRRR GGGGGG BBBBBB 111110 1111111 111110 Cheers, Tom |
From: Bryan Bui-T. <bb...@sp...> - 2008-09-10 15:38:29
|
> > I am using Buildroot and not OE, but my kernel is 2.6.21gum #3 and uBoot > > 1.2.0. I am using Qtopia-Core 4.2.2 and have tested the framebuffer, with > > gradients displaying fine and verified that it is in 16-bit mode. As for a > > simple test case, I create a window and the problem can be seen in the > > title bar. It is displayed as two solid colors, blue on the top half and > > teal on the bottom half (not very pretty). > > > > I have changed the configuration file for Buildroot to build QT-core 4.2.2 > > with only 16-bit depth and still the same results. > > That's probably your problem. I don't think 4.2.2 calculated gradiants in their native > pixel format - it would use RGB888 and then convert to RGB565. Try re- enabling the other > color depths. Or you could try a newer version, say 4.4.1 > Alright, I will give the newer versions a try. Thanks. > > As for hardware, I have grounded the Blue and Red LSB's. Providing the > > full range of colors (RGB 565). > > Is that right? I thought you tie the LSB to the next-LSB? If you simply ground them, white > will actually be a very, very bright green: > > RRRRRR GGGGGG BBBBBB > 111110 1111111 111110 No, it's just not the whitest possible color. Bright green would be 000000 111111 000000 (All green and no blue or red). I think it would work either way, with the LSB tied to the next one or with it grounded. Our hardware has it grounded, and it seems to work pretty well. Regards, Bryan |
From: Bryan Bui-T. <bb...@sp...> - 2008-09-10 16:53:06
|
Tom, I'm trying to build QT-Embedded 4.4.1 and get a lot of errors. The most notable one is: Error: 'QT_END_NAMESPACE' does not name a type. This seems to be the case for many files. Is there a file that was not included that I need to add? Thanks, Bryan > -----Original Message----- > From: gum...@li... [mailto:gumstix- > use...@li...] On Behalf Of Tom Cooksey > Sent: Wednesday, September 10, 2008 12:51 AM > To: gum...@li... > Subject: Re: [Gumstix-users] Gumstix + QT4 @ 16bpp > > On Tuesday 09 September 2008 18:47:37 Bryan Bui-Tuong wrote: > > Hi Tom, > > > > I am using Buildroot and not OE, but my kernel is 2.6.21gum #3 and > uBoot > > 1.2.0. I am using Qtopia-Core 4.2.2 and have tested the framebuffer, > with > > gradients displaying fine and verified that it is in 16-bit mode. As > for a > > simple test case, I create a window and the problem can be seen in > the > > title bar. It is displayed as two solid colors, blue on the top half > and > > teal on the bottom half (not very pretty). > > > > I have changed the configuration file for Buildroot to build QT-core > 4.2.2 > > with only 16-bit depth and still the same results. > > That's probably your problem. I don't think 4.2.2 calculated gradiants > in their native > pixel format - it would use RGB888 and then convert to RGB565. Try re- > enabling the other > color depths. Or you could try a newer version, say 4.4.1 > > > As for hardware, I have grounded the Blue and Red LSB's. Providing > the > > full range of colors (RGB 565). > > Is that right? I thought you tie the LSB to the next-LSB? If you simply > ground them, white > will actually be a very, very bright green: > > RRRRRR GGGGGG BBBBBB > 111110 1111111 111110 > > > > Cheers, > > Tom > > ----------------------------------------------------------------------- > -- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Bryan Bui-T. <bb...@sp...> - 2008-09-10 22:10:45
Attachments:
qtopia4.mk
|
I used the Buildroot's modified qtopia4 package file to configure it. I have attached it to this e-mail Here is a more detailed snippet of the error message: g++ -c -pipe -I/home/bbui/Desktop/gumstix/gumstix-buildroot/build_arm_nofpu/staging_dir/u sr/include -fno-exceptions -g -Wall -W -DQT_BOOTSTRAPPED -DQT_MOC -DQT_NO_CODECS -DQT_LITE_UNICODE -DQT_NO_LIBRARY -DQT_NO_STL -DQT_NO_COMPRESS -DQT_NO_DATASTREAM -DQT_NO_TEXTSTREAM -DQT_NO_TEXTCODEC -DQT_NO_UNICODETABLES -DQT_NO_THREAD -DQT_NO_REGEXP -DQT_NO_QOBJECT -DQT_NO_SYSTEMLOCALE -DQT_NO_GEOM_VARIANT -DQT_NO_USING_NAMESPACE -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../../mkspecs/linux-g++ -I. -I../../corelib/arch/generic -I../../../include -I. -I../../../include/QtCore -I. -I.uic/debug-shared-emb-arm -o debug-shared/generator.o generator.cpp ../../../include/QtCore/../../src/corelib/tools/qstack.h:48: error: expected constructor, destructor, or type conversion before 'typedef' ../../../include/QtCore/../../src/corelib/tools/qstack.h:75: error: 'QT_END_NAMESPACE' does not name a type token.h:265: error: 'Token' does not name a type /home/bbui/Desktop/gumstix/gumstix-buildroot/build_arm_nofpu/staging_dir/usr /include/QtCore/qchar.h:31: error: expected constructor, destructor, or type conversion before 'typedef' ../../../include/QtCore/../../src/corelib/tools/qstack.h:48: error: expected constructor, destructor, or type conversion before 'typedef' ../../../include/QtCore/../../src/corelib/tools/qstack.h:75: error: 'QT_END_NAMESPACE' does not name a type token.h:265: error: 'Token' does not name a type /home/bbui/Desktop/gumstix/gumstix-buildroot/build_arm_nofpu/staging_dir/usr /include/QtCore/qchar.h:31: error: expected constructor, destructor, or type conversion before 'typedef' ../../../include/QtCore/../../src/corelib/tools/qstack.h:48: error: expected constructor, destructor, or type conversion before 'typedef' ../../../include/QtCore/../../src/corelib/tools/qstack.h:75: error: 'QT_END_NAMESPACE' does not name a type token.h:265: error: 'Token' does not name a type /home/bbui/Desktop/gumstix/gumstix-buildroot/build_arm_nofpu/staging_dir/usr /include/QtCore/qchar.h:31: error: expected constructor, destructor, or type conversion before 'typedef' ../../../include/QtCore/../../src/corelib/tools/qstring.h:77: error: expected constructor, destructor, or type conversion before 'typedef' ../../../include/QtCore/../../src/corelib/tools/qstring.h:77: error: expected constructor, destructor, or type conversion before 'typedef' ../../../include/QtCore/../../src/corelib/tools/qstring.h:562: error: 'QBasicAtomicInt' does not name a type ../../../include/QtCore/../../src/corelib/tools/qstring.h: In member function 'QString& QString::operator+=(QChar)': > -----Original Message----- > From: gum...@li... [mailto:gumstix- > use...@li...] On Behalf Of Bryan Bui-Tuong > Sent: Wednesday, September 10, 2008 9:53 AM > To: 'General mailing list for gumstix users.' > Subject: Re: [Gumstix-users] Gumstix + QT4 @ 16bpp > > Tom, > > I'm trying to build QT-Embedded 4.4.1 and get a lot of errors. The > most > notable one is: > > Error: 'QT_END_NAMESPACE' does not name a type. > > > This seems to be the case for many files. Is there a file that was not > included that I need to add? > > Thanks, > Bryan > > > -----Original Message----- > > From: gum...@li... [mailto:gumstix- > > use...@li...] On Behalf Of Tom Cooksey > > Sent: Wednesday, September 10, 2008 12:51 AM > > To: gum...@li... > > Subject: Re: [Gumstix-users] Gumstix + QT4 @ 16bpp > > > > On Tuesday 09 September 2008 18:47:37 Bryan Bui-Tuong wrote: > > > Hi Tom, > > > > > > I am using Buildroot and not OE, but my kernel is 2.6.21gum #3 and > > uBoot > > > 1.2.0. I am using Qtopia-Core 4.2.2 and have tested the > framebuffer, > > with > > > gradients displaying fine and verified that it is in 16-bit mode. > As > > for a > > > simple test case, I create a window and the problem can be seen in > > the > > > title bar. It is displayed as two solid colors, blue on the top > half > > and > > > teal on the bottom half (not very pretty). > > > > > > I have changed the configuration file for Buildroot to build QT- > core > > 4.2.2 > > > with only 16-bit depth and still the same results. > > > > That's probably your problem. I don't think 4.2.2 calculated > gradiants > > in their native > > pixel format - it would use RGB888 and then convert to RGB565. Try > re- > > enabling the other > > color depths. Or you could try a newer version, say 4.4.1 > > > > > As for hardware, I have grounded the Blue and Red LSB's. Providing > > the > > > full range of colors (RGB 565). > > > > Is that right? I thought you tie the LSB to the next-LSB? If you > simply > > ground them, white > > will actually be a very, very bright green: > > > > RRRRRR GGGGGG BBBBBB > > 111110 1111111 111110 > > > > > > > > Cheers, > > > > Tom > > > > --------------------------------------------------------------------- > -- > > -- > > This SF.Net email is sponsored by the Moblin Your Move Developer's > > challenge > > Build the coolest Linux based applications with Moblin SDK & win > great > > prizes > > Grand prize is a trip for two to an Open Source event anywhere in the > > world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > ----------------------------------------------------------------------- > -- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Tom C. <tho...@tr...> - 2008-09-11 06:48:19
|
On Thursday 11 September 2008 00:10:40 Bryan Bui-Tuong wrote: > I used the Buildroot's modified qtopia4 package file to configure it. I > have attached it to this e-mail The makefile seems to be patching configure. Is there any chance of building it outside of buildroot? Have you just bumped the version number in the makefile or was there already a package for 4.4.1? You'll have to excuse my ignorence of buildroot. Cheers, Tom |
From: Bryan Bui-T. <bb...@sp...> - 2008-09-11 17:24:55
|
I have compiled it on my own and still come across the same error. This happens when I first run 'Make' and it is trying to compile moc (/src/tools/moc). Below is my environment and my configuration: (PATHa = path to my gumstix bin) AR=$PATHa/arm-linux-ar \ AS=$PATHa/arm-linux-as \ LD=$PATHa/arm-linux-ld \ NM=$PATHa/arm-linux-nm \ CC=$PATHa/arm-linux-gcc \ GCC=$PATHa/arm-linux-gcc \ CXX=$PATHa/arm-linux-g++ \ CPP=$PATHa/arm-linux-cpp \ RANLIB=$PATHa/arm-linux-ranlib \ OBJCOPY=$PATHa/arm-linux-objcopy \ STRIP="$PATHa/arm-linux-strip --remove-section=.comment --remove-section=.note" #configure QPEHOME=/usr QPEDIR=/usr ./configure -v -platform linux-g++ -embedded arm -xplatform qws/linux-arm-g++ -nomake examples -debug -depths 16 -no-cups -no-nis -qt-freetype -no-accessibility -qt-libmng -qt-gif -system-libjpeg -system-libpng -qt-gfx-transformed -no-kbd-tty -no-mouse-pc -no-qdbus -no-stl -no-sql-db2 -no-sql-ibase -no-sql-mysql -no-sql-oci -no-sql-odbc -no-sql-psql -no-sql-sqlite -no-sql-sqlite2 -no-sql-tds -prefix /usr -prefix-install -L /home/bbui/Desktop/gumstix/gumstix-buildroot/build_arm_nofpu/staging_dir/usr /lib -I /home/bbui/Desktop/gumstix/gumstix-buildroot/build_arm_nofpu/staging_dir/usr /include -qt3support -largefile -little-endian Thanks for all the help. Bryan > -----Original Message----- > From: gum...@li... [mailto:gumstix- > use...@li...] On Behalf Of Tom Cooksey > Sent: Wednesday, September 10, 2008 11:48 PM > To: gum...@li... > Subject: Re: [Gumstix-users] Gumstix + QT4 @ 16bpp > > On Thursday 11 September 2008 00:10:40 Bryan Bui-Tuong wrote: > > I used the Buildroot's modified qtopia4 package file to configure it. > I > > have attached it to this e-mail > > The makefile seems to be patching configure. Is there any chance of > building it outside of > buildroot? Have you just bumped the version number in the makefile or > was there already a > package for 4.4.1? You'll have to excuse my ignorence of buildroot. > > > > Cheers, > > Tom > > ----------------------------------------------------------------------- > -- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Bryan Bui-T. <bb...@sp...> - 2008-09-11 15:44:12
|
I bumped the version number and commented out the use of the .patch file. I also commented out the SED commands and it still gives me these errors. I am going to attempt to copile it outside of buildroot. Will report back with my results. Thank you, Bryan > -----Original Message----- > From: gum...@li... [mailto:gumstix- > use...@li...] On Behalf Of Tom Cooksey > Sent: Wednesday, September 10, 2008 11:48 PM > To: gum...@li... > Subject: Re: [Gumstix-users] Gumstix + QT4 @ 16bpp > > On Thursday 11 September 2008 00:10:40 Bryan Bui-Tuong wrote: > > I used the Buildroot's modified qtopia4 package file to configure it. > I > > have attached it to this e-mail > > The makefile seems to be patching configure. Is there any chance of > building it outside of > buildroot? Have you just bumped the version number in the makefile or > was there already a > package for 4.4.1? You'll have to excuse my ignorence of buildroot. > > > > Cheers, > > Tom > > ----------------------------------------------------------------------- > -- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Terry K. <kl...@kl...> - 2008-09-11 20:49:15
|
On Thu, 2008-09-11 at 08:44 -0700, Bryan Bui-Tuong wrote: > I bumped the version number and commented out the use of the .patch file. I > also commented out the SED commands and it still gives me these errors. I > am going to attempt to copile it outside of buildroot. Will report back > with my results. > > Thank you, > Bryan > FYI, I build qt-embedded-linux-opensource-src-4.4.1 out of buildroot / OE with the following... $./configure -embedded arm -armfpa -depths 8,16,18,24 -qt-mouse-tslib -qt-gfx-vnc -prefix /usr $gmake this enables all depths for gumstix. touchscreen driver and builtin vnc server (which is cool) then set env vars on gumstix export QWS_DISPLAY="VNC:LinuxFB" export QWS_MOUSE_PROTO="tslib:/dev/input/touchscreen0" then run project ./project1 -qws this will run - with a vnc server so you can vncviewer to gumstix ip and control your program. One more thing, I use the OpenEmbedded toolchain in my path. HTH Terry |
From: Casey D. <cas...@gm...> - 2008-09-11 20:59:44
|
From: Dave H. <dhy...@gm...> - 2008-09-11 21:03:34
|
You need to visit this page to unsubscribe: <https://lists.sourceforge.net/lists/listinfo/gumstix-users> > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Tom C. <tho...@tr...> - 2008-09-12 08:44:37
|
On Thursday 11 September 2008 19:24:51 Bryan Bui-Tuong wrote: > I have compiled it on my own and still come across the same error. This > happens when I first run 'Make' and it is trying to compile moc > (/src/tools/moc). Below is my environment and my configuration: > > (PATHa = path to my gumstix bin) > AR=$PATHa/arm-linux-ar \ > AS=$PATHa/arm-linux-as \ > LD=$PATHa/arm-linux-ld \ > NM=$PATHa/arm-linux-nm \ > CC=$PATHa/arm-linux-gcc \ > GCC=$PATHa/arm-linux-gcc \ > CXX=$PATHa/arm-linux-g++ \ > CPP=$PATHa/arm-linux-cpp \ > RANLIB=$PATHa/arm-linux-ranlib \ > OBJCOPY=$PATHa/arm-linux-objcopy \ > STRIP="$PATHa/arm-linux-strip --remove-section=.comment > --remove-section=.note" > > #configure > QPEHOME=/usr QPEDIR=/usr ./configure -v -platform linux-g++ -embedded arm > -xplatform qws/linux-arm-g++ -nomake examples -debug -depths 16 -no-cups > -no-nis -qt-freetype -no-accessibility -qt-libmng -qt-gif -system-libjpeg > -system-libpng -qt-gfx-transformed -no-kbd-tty -no-mouse-pc -no-qdbus > -no-stl -no-sql-db2 -no-sql-ibase -no-sql-mysql -no-sql-oci -no-sql-odbc > -no-sql-psql -no-sql-sqlite -no-sql-sqlite2 -no-sql-tds -prefix /usr > -prefix-install -L > /home/bbui/Desktop/gumstix/gumstix-buildroot/build_arm_nofpu/staging_dir/usr > /lib -I > /home/bbui/Desktop/gumstix/gumstix-buildroot/build_arm_nofpu/staging_dir/usr > /include -qt3support -largefile -little-endian Can you just try to configure with: ./configure -embedded arm -prefix /qt make sudo make install Then tar-up /qt & untar it on your device. I know it's not a great way to install things, but it should work. Cheers, Tom |
From: Bryan Bui-T. <bb...@sp...> - 2008-09-16 01:12:16
|
So I was able to compile and build QT 4.4.1. Thank you for everyone's input. The reason I got those errors was that I added the following: -L /home/bbui/Desktop/gumstix/gumstix-buildroot/build_arm_nofpu/staging_dir/usr /lib -I /home/bbui/Desktop/gumstix/gumstix-buildroot/build_arm_nofpu/staging_dir/usr /include When I removed these lines I was able to compile everything. Do I need to build a version for my Target (Gumstix), copy the files over to the stick, and then build another version for my Host system (with prefix=/gumstix/staging_directory)? Are there any gumstix specific flags I should add when I'm configuring? Regards, Bryan > -----Original Message----- > From: gum...@li... [mailto:gumstix- > use...@li...] On Behalf Of Tom Cooksey > Sent: Friday, September 12, 2008 1:45 AM > To: General mailing list for gumstix users. > Subject: Re: [Gumstix-users] Gumstix + QT4 @ 16bpp > > On Thursday 11 September 2008 19:24:51 Bryan Bui-Tuong wrote: > > I have compiled it on my own and still come across the same error. > This > > happens when I first run 'Make' and it is trying to compile moc > > (/src/tools/moc). Below is my environment and my configuration: > > > > (PATHa = path to my gumstix bin) > > AR=$PATHa/arm-linux-ar \ > > AS=$PATHa/arm-linux-as \ > > LD=$PATHa/arm-linux-ld \ > > NM=$PATHa/arm-linux-nm \ > > CC=$PATHa/arm-linux-gcc \ > > GCC=$PATHa/arm-linux-gcc \ > > CXX=$PATHa/arm-linux-g++ \ > > CPP=$PATHa/arm-linux-cpp \ > > RANLIB=$PATHa/arm-linux-ranlib \ > > OBJCOPY=$PATHa/arm-linux-objcopy \ > > STRIP="$PATHa/arm-linux-strip --remove-section=.comment > > --remove-section=.note" > > > > #configure > > QPEHOME=/usr QPEDIR=/usr ./configure -v -platform linux-g++ - > embedded arm > > -xplatform qws/linux-arm-g++ -nomake examples -debug -depths 16 -no- > cups > > -no-nis -qt-freetype -no-accessibility -qt-libmng -qt-gif -system- > libjpeg > > -system-libpng -qt-gfx-transformed -no-kbd-tty -no-mouse-pc -no-qdbus > > -no-stl -no-sql-db2 -no-sql-ibase -no-sql-mysql -no-sql-oci -no-sql- > odbc > > -no-sql-psql -no-sql-sqlite -no-sql-sqlite2 -no-sql-tds -prefix /usr > > -prefix-install -L > > /home/bbui/Desktop/gumstix/gumstix- > buildroot/build_arm_nofpu/staging_dir/usr > > /lib -I > > /home/bbui/Desktop/gumstix/gumstix- > buildroot/build_arm_nofpu/staging_dir/usr > > /include -qt3support -largefile -little-endian > > Can you just try to configure with: > ./configure -embedded arm -prefix /qt > make > sudo make install > > Then tar-up /qt & untar it on your device. > > I know it's not a great way to install things, but it should work. > > > Cheers, > > Tom > > ----------------------------------------------------------------------- > -- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Tom C. <tho...@tr...> - 2008-09-16 06:47:19
|
On Tuesday 16 September 2008 03:12:09 Bryan Bui-Tuong wrote: > So I was able to compile and build QT 4.4.1. Thank you for everyone's > input. Glad you got things working! > Do I need to build a version for my Target (Gumstix), copy the files over to > the stick, and then build another version for my Host system (with > prefix=/gumstix/staging_directory)? No, you just need to copy the libraries, fonts & plugins to the device. qmake, moc, uic & rcc are all host-binaries. Think of make install as a "install SDK" rather than "install image". Sady, it's up to you to work out what you want on the device. As for options, you could try to enable iwmmx instructions, however they are broken on all but the very-latest versions of gcc. Enabling them should give you a small performance boost when rendering. Cheers, Tom |
From: Bryan Bui-T. <bb...@sp...> - 2008-09-16 17:26:12
|
Thanks. I want to install my QT library under /usr/lib/QT4.4.1, but I do not want to put it there on my host system. How would I keep the QT library in /gumstix/staging/dir/usr/lib and for the gumstix place QT under /usr/lib? Right now I have it with -prefix=/usr/lib/qt4.4.1 and installed under /gumstix/staging/dir, so all the paths are incorrect (since moc, qmake, etc... looks for /usr/lib/qt4.4.1 and not /gumstix/staging/dir/usr/lib/qt4.4.1). Regards, Bryan > -----Original Message----- > From: gum...@li... [mailto:gumstix- > use...@li...] On Behalf Of Tom Cooksey > Sent: Monday, September 15, 2008 11:47 PM > To: gum...@li... > Subject: Re: [Gumstix-users] Gumstix + QT4 @ 16bpp > > On Tuesday 16 September 2008 03:12:09 Bryan Bui-Tuong wrote: > > So I was able to compile and build QT 4.4.1. Thank you for > everyone's > > input. > Glad you got things working! > > > Do I need to build a version for my Target (Gumstix), copy the files > over to > > the stick, and then build another version for my Host system (with > > prefix=/gumstix/staging_directory)? > > No, you just need to copy the libraries, fonts & plugins to the device. > qmake, moc, uic & rcc are all host-binaries. Think of make install as a > "install SDK" rather than "install image". Sady, it's up to you to work > out what you want on the device. > > As for options, you could try to enable iwmmx instructions, however > they are broken on all but the very-latest versions of gcc. Enabling > them should give you a small performance boost when rendering. > > > Cheers, > > Tom > > ----------------------------------------------------------------------- > -- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Bryan Bui-T. <bb...@sp...> - 2008-09-16 21:33:12
|
So after testing out QT4.4, I am still getting an ugly window with no gradients. I compiled it with only 16 bit depth and my Framebuffer is 16-bits. I've tried WindowsXP and Windows and Motif and the title bars in all three of them show blocks of colors instead of a nice gradient. I'm assuming that this is a QT issue and not my hardware or framebuffer because the Framebuffer test shows gradients fine and my colors are not switched (even so, it should still show a gradient). Any Suggestions? It works fine using the Virtual Framebuffer, just not on the Gumstix. Appreciate all the help. > -----Original Message----- > From: gum...@li... [mailto:gumstix- > use...@li...] On Behalf Of Tom Cooksey > Sent: Monday, September 15, 2008 11:47 PM > To: gum...@li... > Subject: Re: [Gumstix-users] Gumstix + QT4 @ 16bpp > > On Tuesday 16 September 2008 03:12:09 Bryan Bui-Tuong wrote: > > So I was able to compile and build QT 4.4.1. Thank you for > everyone's > > input. > Glad you got things working! > > > Do I need to build a version for my Target (Gumstix), copy the files > over to > > the stick, and then build another version for my Host system (with > > prefix=/gumstix/staging_directory)? > > No, you just need to copy the libraries, fonts & plugins to the device. > qmake, moc, uic & rcc are all host-binaries. Think of make install as a > "install SDK" rather than "install image". Sady, it's up to you to work > out what you want on the device. > > As for options, you could try to enable iwmmx instructions, however > they are broken on all but the very-latest versions of gcc. Enabling > them should give you a small performance boost when rendering. > > > Cheers, > > Tom > > ----------------------------------------------------------------------- > -- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Terry K. <kl...@kl...> - 2008-09-16 22:48:44
|
On Tue, 2008-09-16 at 14:33 -0700, Bryan Bui-Tuong wrote: > So after testing out QT4.4, I am still getting an ugly window with no > gradients. I compiled it with only 16 bit depth and my Framebuffer is > 16-bits. I've tried WindowsXP and Windows and Motif and the title bars in > all three of them show blocks of colors instead of a nice gradient. > > I'm assuming that this is a QT issue and not my hardware or framebuffer > because the Framebuffer test shows gradients fine and my colors are not > switched (even so, it should still show a gradient). > > > Any Suggestions? It works fine using the Virtual Framebuffer, just not on > the Gumstix. > > Appreciate all the help. You sure you got an console-LCD16-vx card - not an 18bit?? anyway to test... enable multiple depths as per my previous post... $./configure -embedded arm -armfpa -depths 8,16,18,24 -qt-mouse-tslib -qt-gfx-vnc -prefix /usr if you are interested - here I have a bit of a howto on Qt4 and FPC / Lazarus with a photo of the gumstix running. http://www.klc.net.nz/linux/?page_id=13 also a screenshot here of the vnc viewer and Boa running on desktop generated from gumstix http://www.klc.net.nz/gum-vnc-boa.png program runs on both the 18bit and 16bit boards with no changes. Terry |
From: Bryan Bui-T. <bb...@sp...> - 2008-09-16 23:24:43
|
> You sure you got an console-LCD16-vx card - not an 18bit?? > anyway to test... enable multiple depths as per my previous post... > I am not using the console-LCD at all. I am using a Connex + Breakout GS board w/ the LCD lines (16bits) coming out on there. I compiled with only 16 bits. My display is 18-bit RGB, but I have grounded the Least Significant Bits (LSBs) of Blue and Red, allowing me the full range of 16-bit colors. > $./configure -embedded arm -armfpa -depths 8,16,18,24 -qt-mouse-tslib > -qt-gfx-vnc -prefix /usr > I have configured it in both 16, 18, 24, and 32 bit depths. Still the same results. When I draw a gradient from black -> white, I see the first half as alternating black and green boxes, then the second half is alternating white and blue boxes. What could be the reason for this? The LSB of the blue and red being grounded? -Bryan |
From: Terry K. <kl...@kl...> - 2008-09-16 23:58:49
|
On Tue, 2008-09-16 at 16:24 -0700, Bryan Bui-Tuong wrote: > > You sure you got an console-LCD16-vx card - not an 18bit?? > > anyway to test... enable multiple depths as per my previous post... > > > > I am not using the console-LCD at all. I am using a Connex + Breakout GS > board w/ the LCD lines (16bits) coming out on there. I compiled with only > 16 bits. My display is 18-bit RGB, but I have grounded the Least > Significant Bits (LSBs) of Blue and Red, allowing me the full range of > 16-bit colors. > > > > $./configure -embedded arm -armfpa -depths 8,16,18,24 -qt-mouse-tslib > > -qt-gfx-vnc -prefix /usr > > > > I have configured it in both 16, 18, 24, and 32 bit depths. Still the same > results. > > When I draw a gradient from black -> white, I see the first half as > alternating black and green boxes, then the second half is alternating white > and blue boxes. What could be the reason for this? The LSB of the blue and > red being grounded? > > > -Bryan > Ah. OK, have you had a look at the console-LCD16 schematics to see how the LCD lines are terminated there? http://pubs.gumstix.org/boards/CONSOLE/LCD16/PCB10016-R1833/ |
From: Bryan Bui-T. <bb...@sp...> - 2008-09-17 00:12:05
|
> > > Ah. OK, have you had a look at the console-LCD16 schematics to see how > the LCD lines are terminated there? > > http://pubs.gumstix.org/boards/CONSOLE/LCD16/PCB10016-R1833/ Yes, the Samsung LCD is a 24-bit board, so the Red and Blue have the 3 LSBs grounded and the Green has the 2 LSBs grounded. As for my board, it is 18 bit, so I Only need to ground the LSBs of the Red and Blue. So I don't think this is a hardware issue. -Bryan |
From: Tom C. <tho...@tr...> - 2008-09-17 12:09:13
|
On Wednesday 17 September 2008 00:48:44 Terry Kemp wrote: > if you are interested - here I have a bit of a howto on Qt4 and FPC / > Lazarus with a photo of the gumstix running. > http://www.klc.net.nz/linux/?page_id=13 > > also a screenshot here of the vnc viewer and Boa running on desktop > generated from gumstix > http://www.klc.net.nz/gum-vnc-boa.png That's really cool! It's great to see people using the VNC driver for the exact purpose we developed it for: display-less embedded systems where you want remote-access, but with a rich UI (i.e. not web-based). The application seems to be monitoring a process vessel? Thanks again! Tom |
From: Tom C. <tho...@tr...> - 2008-09-17 11:58:33
|
On Wednesday 17 September 2008 01:24:41 Bryan Bui-Tuong wrote: > > You sure you got an console-LCD16-vx card - not an 18bit?? > > anyway to test... enable multiple depths as per my previous post... > > I am not using the console-LCD at all. I am using a Connex + Breakout GS > board w/ the LCD lines (16bits) coming out on there. I compiled with only > 16 bits. My display is 18-bit RGB, but I have grounded the Least > Significant Bits (LSBs) of Blue and Red, allowing me the full range of > 16-bit colors. Could you run the framebuffer example in Qt and post what it outputs to the console. It could be that you need to do some changes to the kernel to get it to report the correct color format for your display. The LinuxFB screen driver for QWS will ask the kernel how the framebuffer is layed out and adapt (I.e. it doesn't assume 16-bit == RGB565, etc). If the kernel is reporting the wrong format for the framebuffer (quite likely if you haven't modified the kernel) then Qt will obviously write the wrong data to the framebuffer. :-) The example I'm talking about is examples/qws/framebuffer. Cheers, Tom |
From: Bryan Bui-T. <bb...@sp...> - 2008-09-17 18:11:25
|
> Could you run the framebuffer example in Qt and post what it outputs to > the console. It could be that you need to do some changes to the kernel > to get it to report the correct color format for your display. The > LinuxFB screen driver for QWS will ask the kernel how the framebuffer > is layed out and adapt (I.e. it doesn't assume 16-bit == RGB565, etc). > If the kernel is reporting the wrong format for the framebuffer (quite > likely if you haven't modified the kernel) then Qt will obviously write > the wrong data to the framebuffer. :-) > > The example I'm talking about is examples/qws/framebuffer. The example runs fine. The Red, Green and blue boxes appear. I did some gradient drawing (R=G=B from 0->254) and I noticed that a few values (e.g. R=G=B=100) were Green on the Black end of the spectrum and some were blue on the white end of the spectrum, instead of shading from black to white. Here are my results: The framebuffer device was opened successfully. Fixed screen info: id: PXA smem_start: 0xa3401000 smem_len: 153600 type: 0 type_aux: 0 visual: 2 xpanstep: 0 ypanstep: 0 ywrapstep: 0 line_length: 480 mmio_start: 0x0 mmio_len: 0 accel: 0 The framebuffer device was mapped to memory successfully. Opening tty device /dev/tty0 failed: No such file or directory Switch to graphics mode failed: Invalid argument Variable screen info: xres: 240 yres: 320 xres_virtual: 240 yres_virtual: 320 yoffset: 0 xoffset: 0 bits_per_pixel: 16 grayscale: 0 red: offset: 11, length: 5, msb_right: 0 green: offset: 5, length: 6, msb_right: 0 blue: offset: 0, length: 5, msb_right: 0 transp: offset: 0, length: 0, msb_right: 0 nonstd: 0 activate: 0 height: -1 width: -1 accel_flags: 0x0 pixclock: 200000 left_margin: 1 right_margin: 4 upper_margin: 1 lower_margin: 1 hsync_len: 1 vsync_len: 1 sync: 3 vmode: 0 Will draw 3 rectangles on the screen, they should be colored red, green and blue (in that order). Done. |