Re: QtMoko backup/restore
On Thu, 22 Nov 2012 19:59:30 + Neil Jerram n...@ossau.homelinux.net wrote: [cut] My first stab at that is attached below. Comments welcome! Very nice and useful!! Radek, it's pretty alpha and incomplete, but would it perhaps be worth committing already to the repository, so as to have something to build from? Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Kernel panic on Freerunner QtMoko boot
On 11/21/12, Ivan Matveev imatvee...@nm.ru wrote: I had a similar problem. Somehow it went away. See http://lists.openmoko.org/pipermail/community/2012-January/066196.html http://lists.openmoko.org/pipermail/community/2011-December/065998.html Hm. Oddly enough, I tried exactly that (flashing the kernel to u-boot, then reflashing qi, the kernel, and the rootfs all to their correct places), and I'm still getting the same panic. Right now I've got Hackable1 running because it was jffs2, but I'd really like to run QtMoko on my Freerunner. I was able to flash the QtMoko ubifs image a few weeks ago and it worked, so it's odd how nothing seems to be working now. Out of curiosity, why was the switch to ubifs made? Can jffs2 images of QtMoko still be produced? I'm kind of hesitant to try the v26 release because I'd like to have the latest version for my Freerunner. What exact changes would I have to make to my tarball, and how would I go about changing bootloader arguments? I'm not sure if I have Qi installed correctly, which may also be the issue; I flashed it successfully to u-boot, but when I boot while holding AUX to get to DFU mode where I do my flashing I still see U-Boot 1.3.2-moko12 at the top and *** BOOT MENU (NOR) *** as a header. Should I be seeing Qi instead? Any ideas about the above issues? -- Harry Prevor ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Kernel panic on Freerunner QtMoko boot
On Friday, November 23, 2012 03:33:42 PM Harry Prevor wrote: Out of curiosity, why was the switch to ubifs made? ubsifs is faster and can do mmap. On the other side jffs2 images are smaller. Can jffs2 images of QtMoko still be produced? I'm kind of hesitant to try the v26 release because I'd like to have the latest version for my Freerunner. What exact changes would I have to make to my tarball, and how would I go about changing bootloader arguments? You can find and revert the qi commit here: https://github.com/radekp/qi You can easily create jffs2 image from the tarbal as documented here: https://github.com/radekp/qtmoko/blob/master/doc/txt/debian_rootfs_howto.txt I'm not sure if I have Qi installed correctly, which may also be the issue; I flashed it successfully to u-boot, but when I boot while holding AUX to get to DFU mode where I do my flashing I still see U-Boot 1.3.2-moko12 at the top and *** BOOT MENU (NOR) *** as a header. Should I be seeing Qi instead? No you cant see qi, it does not print anything, it just shortyly vibrates and blinks with led. qi is launched just with simple POWER button. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Error compiling on wheezy
Hello Frode, Everyone, following http://ubuntuforums.org/showthread.php?t=652038 , http://frontseed.com/entry/enable-frambeuffer-ubuntu-karmic-koala-using-grub2 and http://news.softpedia.com/news/How-to-Fix-the-Big-and-Ugly-Plymouth-Logo-in-Ubuntu-10-04-140810.shtml, I've been able to enable the fb. The most important steps, in my opinion, could be: * aptitude install v86d * modprobe uvesafb Soon I will try compiling and running QtMoko. Cheers, Giacomo From: EdorFaus edorf...@xepher.net Subject: Re: [QtMoko] Error compiling on wheezy [...] 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 -- ## 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: QtMoko media playback progress?
Neil Jerram n...@ossau.homelinux.net writes:
Radek Polak pson...@seznam.cz writes:
On Wednesday, November 21, 2012 11:29:35 PM Neil Jerram wrote:
Hi Radek,
With current git master (well, actually 052d8d852), I don't see the
progress bar moving when I play a piece of music in the media player.
Do you?
I dont either. The gstreamer looks quite unfinished yet. But it shouldnt be
that hard. You can take insipration how to do it in phonon - it does nearly
the same that we do, e.g. qwidgetvideosink.cpp is nearly the same as our
gstreamerqtopiavideosink.cpp etc..
If you would like to take a look at it, it would be nice.
Sure, I will do that.
The attached patch fixes this.
Regards,
Neil
From 033c9473a840cdfdc9171cae27a204c853efc5aa Mon Sep 17 00:00:00 2001
From: Neil Jerram n...@ossau.homelinux.net
Date: Fri, 23 Nov 2012 23:10:23 +
Subject: [PATCH] gstreamer: generate periodic indication of media playback
position
---
.../mediaengines/gstreamer/gstreamerbushelper.cpp | 22
1 file changed, 22 insertions(+)
diff --git a/src/plugins/mediaengines/gstreamer/gstreamerbushelper.cpp b/src/plugins/mediaengines/gstreamer/gstreamerbushelper.cpp
index b22dbb8..af358d6 100644
--- a/src/plugins/mediaengines/gstreamer/gstreamerbushelper.cpp
+++ b/src/plugins/mediaengines/gstreamer/gstreamerbushelper.cpp
@@ -37,12 +37,14 @@ public:
this-m_helper = helper;
setParent(helper);
m_tag = gst_bus_add_watch_full(bus, 0, busCallback, this, NULL);
+ m_intervalTimer-start();
}
void removeWatch(BusHelper* helper)
{
Q_UNUSED(helper);
g_source_remove(m_tag);
+ m_intervalTimer-stop();
}
static BusHelperPrivate* instance()
@@ -50,7 +52,26 @@ public:
return new BusHelperPrivate;
}
+private slots:
+void interval()
+{
+emit m_helper-message(Message());
+}
+
private:
+BusHelperPrivate()
+{
+m_intervalTimer = new QTimer(this);
+m_intervalTimer-setInterval(250);
+
+connect(m_intervalTimer, SIGNAL(timeout()), SLOT(interval()));
+}
+
+~BusHelperPrivate()
+{
+delete m_intervalTimer;
+}
+
void processMessage(GstBus* bus, GstMessage* message)
{
Q_UNUSED(bus);
@@ -65,6 +86,7 @@ private:
guint m_tag;
BusHelper* m_helper;
+QTimer* m_intervalTimer;
};
#else
--
1.7.10.4
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
