Gausen
Member
Thank you Exophase! It's impressive to watch you work, you clearly know whats happening every time.
Well you know its all about whether or not the floating points conflict with the opengles drivers or the SOC is compatible with the main cpu or neon sub-categorises with the gpu or vise-versa. Or using the main memory with or without a swap to defer a crash frame by frame by offloading the inputs to a subscript allocated on the nand or preferably some external space. Or something like that..
So did you think this was a clever comment or did you just want to showcase your ignorance?Well you know its all about whether or not the floating points conflict with the opengles drivers or the SOC is compatible with the main cpu or neon sub-categorises with the gpu or vise-versa. Or using the main memory with or without a swap to defer a crash frame by frame by offloading the inputs to a subscript allocated on the nand or preferably some external space. Or something like that..
Do I smell troll?Well you know its all about whether or not the floating points conflict with the opengles drivers or the SOC is compatible with the main cpu or neon sub-categorises with the gpu or vise-versa. Or using the main memory with or without a swap to defer a crash frame by frame by offloading the inputs to a subscript allocated on the nand or preferably some external space. Or something like that..
Whether it is or not I have to at least add some way to communicate this >_> I think closing the Pandora lid may screw up other things so maybe not a good idea.I wonder, is it possible for user mode applications such as DraStic to detect closing the Pandora? It would be cool if that was emulated just like closing the DS (low power mode included), especially since there are a few games that actually use the clamshell closing as part of gameplay (e.g. solving a puzzle in Zelda) or to play a sound (Super Mario 64 DS).
There's a fresh sheet here, just waiting to be populated. (Thanks Linux-SWAT)Astonoshing speed improvements, even on my CCPandora! Thanks Exophase, this is so impressive!
Is there a new compability sheet or should we just post everything here? I've got quite some bugs to report
Closing the Pandora lid calls "/usr/pandora/scripts/op_power.sh 1 lid", which can do several things depending on config - I think the default is to disable the screen, which should be no problem I think. Of course if it's set to suspend, then you can't hope to be able to do anything in DraStic since you will have to wait until it resumed. You can check /tmp/powerstate to find out if the lid is closed. Just checking that file two times per second or so should be enough, the overhead should be small since /tmp is in RAM.Whether it is or not I have to at least add some way to communicate this >_> I think closing the Pandora lid may screw up other things so maybe not a good idea.I wonder, is it possible for user mode applications such as DraStic to detect closing the Pandora? It would be cool if that was emulated just like closing the DS (low power mode included), especially since there are a few games that actually use the clamshell closing as part of gameplay (e.g. solving a puzzle in Zelda) or to play a sound (Super Mario 64 DS).
If you want controls for a Phone an optional onscreen button would be the best solution.Apparently it's also a standard /dev/input event you can read in gpio-keys (thanks to Cloudef for the def), so I don't think I'll have to poll anything. Should be trivial to implement. Just need something else for the non-Pandora users.