Preparing for a Prototype


Djoga'Ro said:
Seeing it sitting there like that, how does the hinge do/feel?
Maybe the screen would be less foggy in the picture, if the it was tilted further upwards in this situation.
Click to expand...
Hinge feels excellent. The only 'lock point' for the hinge is at full open (flat).
If I tilt it more upwards all you are going to see is the reflection of the camera/phone and my ugly head behind it. The reflections are not bad when using it, but getting a good picture of the screen while on seems to be difficult. The 'fog' is also due to taking a still picture of an animated screen. Others seem to have a much better set up for pictures and video - I'll leave them to it.
Post automatically merged:

sebt3 said:
Yet this might not work since that wasnt build for buster but stretch. Give me some days to setup a dev env and build this one, supertux and dosbox :)
Click to expand...

Will do - please post back up when you're ready for me to dive into more of it!
 
FWIW it's worth mentioning that as far as I know the nubs are still working like the pandora was, just using much more reliable and accurate nubs. It doesn't make use of their center clickability, and thus sliding left on the right nub to simulate a left click probably takes some learning to anyone new to it. I expect this to change at some point.
 
docbroke said:
@Grench how does the nubs work as a mouse ?
Click to expand...
The nubs...
The great: Right now the left mouse nub moves the pointer, and does so far more accurately than the Pandora ever could.
The OK: The right mouse nub manages left/right click. Nub left is left click, nub right is right click. Currently right nub up does not seem to be working as 'double click' (that is how Pandora works). I suspect that what we have now is a temporary solution to get it usable until the software can get sorted out.
The weird: My left nub lightly jingles when moving around. The right nub lightly clicks. It feels/sounds like there are springs inside that are stretching. It isn't bad, but is there. I'll take that for the greater accuracy.

*************************
Heat...
Last night I played Hostile Takeover (Warfare Inc) for about two hours straight. This is one of those single threaded games that will consume whatever CPU power is available to it. I.e. it pegs one core worth of CPU continuously. I can see this visually on Gkrellm. According to Gkrellm, after that play session, one of the Pyra's internal temp sensors was reading 51*C. The Pyra was warm to the touch. I pulled the battery - warm as well. I grabbed my laser thermometer and checked it. Battery was at 120*F (48*C). Pointing the laser inside the battery compartment at roughly where the CPU board sits yielded a reading of 125*F (51.6*C). During that play session my battery - as measured on the noted inaccurate OS battery meter - went from 92% to 57% and claims over 5 hours remaining.

An idea for less heat and lower battery use?
Does the .dbp system have any handles in it to -restrict- the CPU that a game like this can see/draw? I'm betting that the game itself would still be 'the same' with half a core as it does when it is consuming a whole core worth of processing. I'm wondering if we can have a setting in one of the .dbp files to control how much processing power that individual .dbp application is allowed to consume. There are a lot of games out there that simply let the 'AI' consume any and all CPU that the game can see whether it needs it or not. I don't want to throttle the whole system, just what any single .dbp application can see/use of the system. Thoughts?
 
I'd have throught throttling settings would be better applied across the OS as a whole if you need them for something debian that's stressting the CPUs unnecessarily. For DBPs the code itself could be better designed to limit how much CPU bandwidth it consumes at max I'd hope, though I don't really have a handle on how to acheive that.

It's also worth noting that measuring CPU bandwidth alone is largely irrelevant; the main control for these devices is the CPU frequency. The Pandora let us choose our own maximum frequencies, which is something I'd not like to lose without a fight personally.
 
Is 51°C too hot? The GPD MicroPC is almost always around that temperature, and goes up if I start doing things like watching videos.
 
51 degrees is hotter than Australia right now, but for consumer electronics it's not too extraordinary. My server box is currently at 59 degrees and that's just transcoding a video at the moment, but that's the CPU sensor alone, and that doesn't reach the outside of the case at all. 48 degrees for the battery is on the warm side but actually not too shabby for two hours of stressing the CPU, at whatever clock that's set at currently (you can get that by catting /sys/class/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq on my build machine, although you need superuser privilidges to read that file)
 
There are a lot of things that can improve the heat dissipation right now.
Everything is ALWAYS on at the moment. The accelleration sensor constantly spams the system with events (not even a deadzone is configured yet), the modem is always on (even without a SIM card in there), GPS is always active, etc.
Hardware acceleration is missing for a lot of things (audio, graphics, etc.), so this will produce extra heat as well.

And: The final units will have a silicon mat between the battery compartment and the PCB which will shield some heat from the battery.

About the nubs: Yes, the current setup is just a temporary solution so you can use them. In the end, the right nub click will be a left mouse click and vice versa.
And yes, there's a spring in there :)
 
In the end, the nubs are simply supposed to be xinput devices. So you can set them up however you like.
 
I recommend the right nub be scroll, and the left be cursor movement, by default. How will middle click work?
 
Nubs: I think how they were envisioned to work with clicks is: Left nub mouse movement, right nub scroll. Left mouse nub click is right mouse button. Right mouse click is left mouse button. About now people are screaming at their monitor about this being reversed. The nubs do not move while clicked. Left mouse click + hold to drag is a thing. Right mouse click normally pulls open a menu. Work it through - it makes sense.

Nubs part II: We need Super Geometry Dust for the Pyra. That game was/is the ideal way to show off what a pair of nubs could do on the Pandora now Pyra. Does anyone have a method where they can bug the author?

Shoulder buttons: My left shoulder buttons (Fn top, Shift lower) have been working fine now that I've been booting from a stable OS in the left SD slot. Last night I was fiddling with Gkrellm and Hostile Takeover (Warfare Inc) and wanted to flip between them using right shoulder button (alt) + tab. It didn't work. Center keyboard Alt + Tab works. Are the right shoulders not mapped to Alt & Ctrl yet?

Heat: I was reporting on how hot I got it with continuous game play, not complaining about it. The unit was warm but still hold-able. That was 'as hot as it gets' with a single-threaded process pegging the CPU for two hours (steady state).

Restricting how much CPU a .dbp (or other application) can use: There are a lot of games like this (Hostile Takeover, Neverwinter Nights as examples) where the program will use the entirety of 1 CPU core regardless of how fast that 1 core is. Whether it is consumed with an AI or additional detail rendering or secondary preemptive processing, these exist and are a thing. The games may be equally playable on a tenth of the CPU core they are taking, but will consume the whole core's worth regardless. Is there a mechanism in Linux to limit an application to only X cycles or y% of 1 CPU core or such? I don't want to underclock the whole system to keep an overly greedy application in check.

A game that plays nice on CPU/battery: I want to see how many hours of game play I can reasonably get on a single charge with WiFi off, backlights lowish. An ideal game for this would be Vulture's Eye. No AI, no continuous background processing to speak of. Won't tax the CPU. Will Pyra even get warm?
 
Silent-Hunter said:
I recommend the right nub be scroll, and the left be cursor movement, by default. How will middle click work?
Click to expand...
Yes, that would be fairly intuitive too, so I wouldn't object to that. I don't personally use scroll wheels or anything like that; I find on most systems I interact with that the arrow keys plus page up/down do the work for me, although I guess dedicated scroll wheels have the benefit that I don't need to find a non-interactive part of a page to click focus on before the keys stop modifying that text or whatever.
 
levi said:
Yes, that would be fairly intuitive too, so I wouldn't object to that. I don't personally use scroll wheels or anything like that; I find on most systems I interact with that the arrow keys plus page up/down do the work for me, although I guess dedicated scroll wheels have the benefit that I don't need to find a non-interactive part of a page to click focus on before the keys stop modifying that text or whatever.
Click to expand...
Where right nub as scroll will really come into play is on websites where the text is really small. Ctrl+(+) to increase font to where it is readable on a 5" screen will often throw in a horizontal scroll bar. Right nub side-side to read and scroll through the page.
 
You must log in or register to reply here.

Similar threads

ekianjo
Impressions of A Pyra Prototype (Back in 2017)
Replies
13
Views
5K
ekianjo
ekianjo
EvilDragon
Pyra Prototype Videos - Askarus Edition
2 3 4
Replies
63
Views
23K
MrLimatex
MrLimatex
ptitSeb
Pictures, Videos and thoughts of a Pyra dev-prototype
11 12 13
Replies
244
Views
63K
Djoga'Ro
Djoga'Ro
ClockworkCoder
Preparing for the countdown...
2 3 4
Replies
63
Views
11K
levi
levi
directive0
Pyra Enclosure Swapping and Modification Questions
Replies
1
Views
2K
directive0
directive0
Back
Top