Firmware Testing


Aninhumer said:
Actually, I was wondering, will the auto created .desktop files be accessible with the D-Pad, as they would be on a simple menu? Or is it touchscreen/nub mouse only?

Or alternatively, would it be possible to run PMenu in XFCE as a fullscreen app? So you could have a simple menu for gaming, and then drop out of it to do anything else?

I mean, I realise 10 seconds or whatever isn't a lot of time to swap over, but if it could be instant, that would be nice.

Yes, of course you can always switch from XFCE4 to PMenu and vice versa on the fly (XFCE4 will quit though, PMenu doesn't run using X).
 
Last edited:
EvilDragon said:
Yes, of course you can always switch from XFCE4 to PMenu and vice versa on the fly (XFCE4 will quit though, PMenu doesn't run using X).

How is that? how will it launch X-based apps? does that mean that the apps, games, emulators that PMenu will run will be only the framebuffer based ones? and what about 3D acceleration, does it work on framebuffer, without X?

is the login manager a XDM? if so, will it kill itself and X to run PMenu?


I'm a bit puzzled here :blink:
 
Last edited by a moderator:
efegea said:
EvilDragon said:
Yes, of course you can always switch from XFCE4 to PMenu and vice versa on the fly (XFCE4 will quit though, PMenu doesn't run using X).

How is that? how will it launch X-based apps? does that mean that the apps, games, emulators that PMenu will run will be only the framebuffer based ones? and what about 3D acceleration, does it work on framebuffer, without X?

It will simply run X programs by starting an X-Server and running them.

The Login Manager is SLIM, not XDM.
 
Last edited:
EvilDragon said:
* Include Battery-Status (it charges, but it can't read out the current status yet)

This confuses me, I remember many months ago the explanation of the battery gauge being so accurate (Down to minutes maybe even seconds?) and that was something we were just going to be amazed by (no more 3, 2 , 1 Status bar crap). I thought it was this gauge that determined the battery was more like 14 hours than ten? If they aren't reading status, then how was the previous determined? Or it was working once but not after a change or something? Having talked about the coolness of the battery gauge I'm just curious as to why it isn't working if at one time it seemed to be.
Thanks.
 
Last edited by a moderator:
Poem58 said:
EvilDragon said:
* Include Battery-Status (it charges, but it can't read out the current status yet)

I thought it was this gauge that determined the battery was more like 14 hours than ten? If they aren't reading status, then how was the previous determined?
Thanks.

They ran a Snes emulator on (IIRC) the original FDM-cased prototype which ran for (again, IIRC) 8 hours, stating that battery management (implemented in the future) would probably increase this to 10+ hours for games and 12+ for general purpose applications. The battery indicator, AFAIK isn't part of this management, it just reads values from the system process which is. In XFCE you can make a gauge for just above any system variable if you so wish.
 
Last edited by a moderator:
EvilDragon said:
I guess in January (latest) you can simply suspend the unit like a normal PDA and then you don't need to reboot each time you use the unit.
Optimistic as usual. All drivers will need to have support for that to work, but almost none of them do now.

Poem58 said:
This confuses me, I remember many months ago the explanation of the battery gauge being so accurate (Down to minutes maybe even seconds?) and that was something we were just going to be amazed by (no more 3, 2 , 1 Status bar crap). I thought it was this gauge that determined the battery was more like 14 hours than ten? If they aren't reading status, then how was the previous determined? Or it was working once but not after a change or something? Having talked about the coolness of the battery gauge I'm just curious as to why it isn't working if at one time it seemed to be.
Thanks.
The chip works properly but the driver needs to be written.

Remember that software is done by volunteers with unrelated day jobs on their free time. Don't expect everything to work 100% on day 1.
 
Last edited by a moderator:
notaz said:
EvilDragon said:
I guess in January (latest) you can simply suspend the unit like a normal PDA and then you don't need to reboot each time you use the unit.
Optimistic as usual. All drivers will need to have support for that to work, but almost none of them do now.

Naaah, I'm not craig ;)
I thought the driver was already finished. Sorry if that isn't the case :)
Will follow as soon as possible though :)

And for a first release, the OS works great (methinks :))
 
Last edited:
dflemstr said:
EvilDragon said:
And for a first release, the OS works great (methinks :) )

Uh-oh.... When ED thinks something works great... well, we all know what happens then...

:D Well, the difference is - only cool community guys involved (no company) and I already have the OS at home to play around with :D
 
Last edited:
Thanks for the answer, but no I wasn't Expecting everything to work from day one, I was confused due to the fact that when (M Weston I believe) talked about this many months ago it sounded fully operational and he was describing it as so cool we'd love it. Didn't sound like something "to come later" but something he was describing as if he was already experienced in it's execution, which is why I asked. Seems that so many things have been answered ambiguously that nearly everything we think we know is always best described as wait until we have it in our hands, otherwise, it's all just conjecture.
 
Poem58 said:
This confuses me, I remember many months ago the explanation of the battery gauge being so accurate (Down to minutes maybe even seconds?) and that was something we were just going to be amazed by (no more 3, 2 , 1 Status bar crap). I thought it was this gauge that determined the battery was more like 14 hours than ten? If they aren't reading status, then how was the previous determined? Or it was working once but not after a change or something? Having talked about the coolness of the battery gauge I'm just curious as to why it isn't working if at one time it seemed to be.
Thanks.
The "fuel gauge" is a special chip (or part of a special chip) for monitoring battery status. I think he means that it just doesn't show in the GUI yet.
 
Last edited by a moderator:
EvilDragon said:
It will simply run X programs by starting an X-Server and running them.

The Login Manager is SLIM, not XDM.

But wouldn't it slow-down the launching of apps? does the X server load fast?

With XDM I meant X Display Manager, like saying "is SLIM a login manager that runs on X, like kdm or gdm?", I were not talking about that ugly and simple X display manager that is called XDM :p

So that means that SLIM runs on framebuffer. Understood :) That makes me think about Pangea, as it was written for running on X, although it can be run on framebuffer, as Qt is capable to do so, but it could mean that Pangea wouldn't be hardware-accelerated..

Agh..again that feeling that makes me think that I'm writing a launcher to collaborate with the team, but I feel "far away" from the team, like as I were alone: me with my launcher and nobody else cares..there is not communication, strange, as Pangea were confirmed to be an application that would be included on future firmware updates.. Should I quit? there isn't a need for Pangea now that Pmenu is working well..
 
Last edited by a moderator:
efegea said:
EvilDragon said:
It will simply run X programs by starting an X-Server and running them.

The Login Manager is SLIM, not XDM.

But wouldn't it slow-down the launching of apps? does the X server load fast?

With XDM I meant X Display Manager, like saying "is SLIM a login manager that runs on X, like kdm or gdm?", I were not talking about that ugly and simple X display manager that is called XDM :p

So that means that SLIM runs on framebuffer. Understood :) That makes me think about Pangea, as it was written for running on X, although it can be run on framebuffer, as Qt is capable to do so, but it could mean that Pangea wouldn't be hardware-accelerated..

Agh..again that feeling that makes me think that I'm writing a launcher to collaborate with the team, but I feel "far away" from the team, like as I were alone: me with my launcher and nobody else cares..there is not communication, strange, as Pangea were confirmed to be an application that would be included on future firmware updates.. Should I quit? there isn't a need for Pangea now that Pmenu is working well..
Personally, I think that your pangea project shows a lot more promise than pmenu, and I haven't even seen the latest version of pangea!

Just the design decision to build a modular GUI instead of a GUI that is built up with the principle that "dialogs have to be X*Y pixels in size, have this-and-that .BMP format" and so on. With your approach, I believe that it's possible to do something more exciting, like for example having switchable wallpapers in the launcher, interactive applets (like a battery indicator, which pmenu doesn't have), and other things that are more poweruser-ish and/or more feature-rich. I'm not assuming that pangea can do all of this yet, but you're at least leaving the option open.

I'd really like to see your latest build of pangea, is the source code public on e.g. GitHub yet?
 
Last edited by a moderator:
Wait, you're saying the people working on the panda are hard to get ahold of? *sniff* You've never written to me about pangea, and if you're working on a launcher strikes me as I might be someone you might've wanted to write to. Ha, busted, you didn't try very hard to talk to folks ;)

jeff

edit: as to quitting.. write software because you feel there is a need, or for fun (hopefully both.) Know that there are hundreds of window managers for X11 .. was there a need? Scratch your itch my friend. Is there a need? *yes!*
 
notaz said:
Optimistic as usual. All drivers will need to have support for that to work, but almost none of them do now.
Shouldnt TI ship such Driver-stuff straight together with their Chips? I always thought, important Drivers are done by the guys who actualy also build the Hardware, not the Software for a Device (for example: I don't think Microsoft writes the Graphic-Drivers for NVidia or ATI or the MAinboard Drivers for Mainboard Companies). ^_^
Why does the OP-Team/Comunity has to do all this boring basic stuff? (Yes, the Pandora is a complete new Device but the Parts it contains aren't.)
AND I also thought the Pandora-Devs working since the beginning onto the Basic Software (all in all more than 2 Years I guess)? Wow, As a noob I only can say, this driver-coding seems to be really a hard task if it takes so long, another reason why TI should do this along with the OMAP and the Pandora-Mainboard. But naive as I was I really thought, this stuff works out of the box or is somehow a standard part of a average Linux-Kernel. ( "Hello, I'm the Linux OS, oh, I see I run onto a ARM mobile device, ok, full Power-management enabled, done. Have a nice day..." :lol: ) Seems not to be.

A mobile Device without working Power-Management can't be a good thing, so lets hope it will be done as fast as possible. I know it will work some day, so no big deal, I really don't want to complain. :)
 
Last edited by a moderator:
Back
Top