Re: [Gta04-owner] No gta-04 available
Le 30 oct. 2012 à 17:27, Al Johnson a écrit : > On Monday 29 October 2012 20:16:34 Michael Parchet wrote: >> Hello, >> >> The switzerland mobile phone providers will prepare the LTE (4g) network. >> >> Do you think to make a 4g matherboard "gta05" ? > > Option now have LTE modules, but they are a little bigger than the gtm601u in > the GTA04 so aren't quite a drop-in replacement. They do say the 601 will fit > on the footprint of the 801 though, so they are probably electrically > compatible. > http://www.option.com/en/products/products/lgamodulegtm801u/ Hello, Do you test this 4g card in a freerunner ? Is this card compatible 3g ? Best regarda mparchet > >> In my opinion, with only a 3g maserboard, the future freerunner will >> be quickly out of date. >> >> Whath's your opinion ? > > Any low volume product that isn't backed by a big corporate is going to be a > bit behind the times simply because the manufacturers won't release > > That said, the 4G issue looks like a relatively easy problem to solve. > Getting > the economics to work seems to be the biggest hurdle at the moment. > >> Best regards >> >> mparchet > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Error compiling on wheezy
Hi, The following contains a good bit of guesswork and assumptions, so please correct me if I'm wrong anywhere. There's also some bits which may seem obvious, but I don't know what you would find obvious and not - and besides, sometimes it's easy to miss things that are obvious in hindsight, so I figured it best to include as much as I could think of, even if you've already tried it. On 11/08/2012 04:50 PM, Giacomo 'giotti' Mariani wrote: Hello Radeck, everyone, I successfully built QtMoko in chroot on a Squeeze VirtualBox machine with target PC :-) If I understand you correctly, your setup has three major parts: (A) the host PC (actual physical PC), running some form of Linux (B) a VirtualBox virtual computer, running Debian Squeeze (C) a chroot used to build QtMoko with (C) being inside of (B), (B) running on (A), and (B) being intended solely for the purpose of building/running QtMoko, and nothing else. (Btw, that's pretty much exactly how I would do it myself - I haven't, yet, but probably will (even if only to try to scratch a few itches), so I'm glad someone's working out the kinks. ;) ) Fairly complex setup, actually, so lots of places things can go wrong. ...but now I can't run it: what do you mean by * Now switch to first console (CTRL+ALT+F1) and run it: I'm assuming that your (B) is a minimal installation, not running any graphical environment (aka X11 or X.org), just giving you a CLI console. If so, the above bit should be ignored, as it would typically make your host PC (A) switch to its console. However, if you *are* running a GUI in the virtual box, I think the easiest thing to do would be to turn it off and disable it, so it doesn't get in the way. (I don't actually think this is where you have problems, though.) If I do it under chroot I get: qtmoko-chroot:/opt$ qpe QScreenLinuxFb::connect: No such file or directory Error opening framebuffer device /dev/fb0 LinuxFb: driver cannot connect Aborted > Indeed, I miss /dev/fb0. Where can i get it? Hm. No framebuffer device... My first thought would be to check if /dev is actually bind mounted properly, so that the out-of-chroot udev in (B) would take care of generating /dev/fb0 for both (B) and (C). I see that the script used to enter the chroot tries to take care of that though, so it probably is (but it wouldn't hurt to check). One way to check would be to see if /dev/fb0 exists on (B) even though it doesn't in (C). Assuming that's not the problem, my next thought is to check the configuration of VirtualBox, checking that it is actually set up to include a graphics card that Linux can run a graphical framebuffer on. If it is, I think the next thing to do is to check the dmesg of (B) (if the output of "dmesg" is too short, it can probably be found in /var/log/messages prefixed with "kernel:"), looking for anything to do with framebuffers, to see if that tells you why (B) doesn't have one. If that doesn't give any clues either, well... then things are a bit more complex. Maybe the right driver wasn't enabled when (B)'s kernel was compiled, or something. Either way, probably harder to figure out than we'd like. :/ So I hope something in the above helps. The same happens if I do it outside chroot (connecting with ssh -Y): Just a tiny note: the -Y is probably not necessary, as it just deals with forwarding X11 connections - which are not in use here. It shouldn't hurt, either, though - and should certainly not cause the problem you're seeing. Regards, -Frode ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Error compiling on wheezy
On Thursday, November 08, 2012 04:50:03 PM Giacomo 'giotti' Mariani wrote: > Hello Radeck, everyone, >I successfully built QtMoko in chroot on a Squeeze VirtualBox machine > with target PC :-) Nice :) > ...but now I can't run it: what do you mean by > > * Now switch to first console (CTRL+ALT+F1) and run it: > > . /opt/qtmoko/qpe.env > qpe > ? > > If I do it under chroot I get: > > qtmoko-chroot:/opt$ qpe > QScreenLinuxFb::connect: No such file or directory > Error opening framebuffer device /dev/fb0 > LinuxFb: driver cannot connect > Aborted Hmm interesting - i thought every linux has /dev/fb0. So it really does not exist? > PS I would change the README as follow: Done, thanks! Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Error compiling on wheezy
Hello Radeck, everyone, I successfully built QtMoko in chroot on a Squeeze VirtualBox machine with target PC :-) ...but now I can't run it: what do you mean by * Now switch to first console (CTRL+ALT+F1) and run it: . /opt/qtmoko/qpe.env qpe ? If I do it under chroot I get: qtmoko-chroot:/opt$ qpe QScreenLinuxFb::connect: No such file or directory Error opening framebuffer device /dev/fb0 LinuxFb: driver cannot connect Aborted The same happens if I do it outside chroot (connecting with ssh -Y): $ . /opt/qtmoko/qpe.env jack@QtDebian:/home/jack$ export LD_LIBRARY_PATH=/home/jack/qtm/qtmoko-chroot/usr/lib/:/home/jack/qtm/build-pc/image/lib/:/home/jack/qtm/qtmoko-chroot/lib/ jack@QtDebian:/home/jack$ qpe QScreenLinuxFb::connect: No such file or directory Error opening framebuffer device /dev/fb0 LinuxFb: driver cannot connect Aborted Indeed, I miss /dev/fb0. Where can i get it? Thanks a lot and best regards, Giacomo PS I would change the README as follow: $ git diff diff --git a/README b/README index 7868bf2..9bcbf83 100644 --- a/README +++ b/README @@ -120,8 +120,11 @@ PC build * It's now possible to build QtMoko for x86 without cross compiling. This is great for development. Just do: +mkdir -p /root/qte/build-pc +cd /root/qte/build-pc ../qtmoko/configure -device pc make +export LD_LIBRARY_PATH=/root/qte/build-pc/qtopiacore/host/lib/ make install * To run the image you need to be root and symlink the result image to opt: diff --git a/qtopiacore/qt b/qtopiacore/qt --- a/qtopiacore/qt +++ b/qtopiacore/qt @@ -1 +1 @@ -Subproject commit a5c5ee0bbe93b3fab92d669576776b663f567cef +Subproject commit a5c5ee0bbe93b3fab92d669576776b663f567cef-dirty -- ## giacomo 'giotti' mariani gpg --keyserver pool.sks-keyservers.net --recv-key 0x99bfa859 O< ASCII ribbon campaign: stop HTML mail www.asciiribbon.org ## ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Missing icons in current QtMoko git build
On Thursday, November 08, 2012 09:51:25 AM Neil Jerram wrote: > There are 2 new files in the Arora patch that I think haven't yet been > added to the Git repository... Ups, i again forgot about them. Fixed now. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QWSLock errors
On Thursday, November 08, 2012 09:12:40 AM Neil Jerram wrote: > With current QtMoko git I'm seeing a lot of QWSLock errors in my log, > e.g.: > > root@neo:~# tail -f /var/log/messages > Nov 8 08:01:05 neo Qtopia: QWSLock::down(): Invalid argument > Nov 8 08:01:05 neo Qtopia: QWSLock::down(): Invalid argument > Nov 8 08:01:05 neo Qtopia: QWSLock::up(): Invalid argument > Nov 8 08:01:05 neo Qtopia: QWSLock::down(): Invalid argument > Nov 8 08:01:05 neo last message repeated 3 times > Nov 8 08:01:05 neo Qtopia: QWSLock::up(): Invalid argument > Nov 8 08:01:35 neo last message repeated 4 times > Nov 8 08:01:35 neo Qtopia: QWSLock::down(): Invalid argument > Nov 8 08:01:36 neo Qtopia: QWSLock::up(): Invalid argument > > Are you getting those too? If so, perhaps this is something to > understand before making a new release. > > I'm investigating by adding more logging to QWSLock::up() - I hope to be > able to say more this evening. To me it looked that the semaphore was closed by the other process or thread. The logging and some other stuff was added there in Qt 4.8. You can check the git log on qwslock.cpp. > (For some reason a simple 'make', or even '../qtmoko/configure -device > gta04 && make', doesn't rebuild qwslock.c and the QtGui library. So > I've kicked off a full rebuild.) I alsa had to rebuild it all for changes in Qt. I tried make and make install in build/qtopiacore/target but IIRC it didnt help. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Missing icons in current QtMoko git build
Radek Polak writes: > On Wednesday, November 07, 2012 10:47:51 PM Neil Jerram wrote: > >> If you're thinking of a release soon, I have a couple of safe (I >> believe) things that you might want to include in that. First, the >> support for Arora to provide the "WebAccess" service, which makes it >> work to click on URLs in emails and other places - this is a patch for >> the Arora submodule. Second, a tweak to the Mokofaen theme so that it >> has room for displaying >=10 satellites in the title bar. I've attached >> those below. > > Both are applied, thanks! There are 2 new files in the Arora patch that I think haven't yet been added to the Git repository... Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QWSLock errors
With current QtMoko git I'm seeing a lot of QWSLock errors in my log, e.g.: root@neo:~# tail -f /var/log/messages Nov 8 08:01:05 neo Qtopia: QWSLock::down(): Invalid argument Nov 8 08:01:05 neo Qtopia: QWSLock::down(): Invalid argument Nov 8 08:01:05 neo Qtopia: QWSLock::up(): Invalid argument Nov 8 08:01:05 neo Qtopia: QWSLock::down(): Invalid argument Nov 8 08:01:05 neo last message repeated 3 times Nov 8 08:01:05 neo Qtopia: QWSLock::up(): Invalid argument Nov 8 08:01:35 neo last message repeated 4 times Nov 8 08:01:35 neo Qtopia: QWSLock::down(): Invalid argument Nov 8 08:01:36 neo Qtopia: QWSLock::up(): Invalid argument Are you getting those too? If so, perhaps this is something to understand before making a new release. I'm investigating by adding more logging to QWSLock::up() - I hope to be able to say more this evening. (For some reason a simple 'make', or even '../qtmoko/configure -device gta04 && make', doesn't rebuild qwslock.c and the QtGui library. So I've kicked off a full rebuild.) Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
