Preparing for a Prototype


Since this is a debian, it has to, otherwise, systemd is very unhappy
The second half of the question; can this be tied into the .dbp for applications like Hostile Takeover that are CPU greedy?
 
The second half of the question; can this be tied into the .dbp for applications like Hostile Takeover that are CPU greedy?
Games, by definition, are CPU greedy, since they try to reach the highest fps.
Beside cGroups, there's many options : The best one still is : cap the fps at 60 with vsync. Then reducing the cpu frequency sound like a good plan too (at least turn the gouvernor to conservative).
cGroups cpu-share make no points since when you're playing, there's only that game trying to bog the CPU. So no matter how low the ratio you give to the game, it will still bog 100% of the CPU.
Then there's cGroups cpu-set. You could limit the game to a single core. But then, I guess, Hostile Takeover only use one anyway (since it has been designed for a single core machine).
If you're after saving battery and produce less heat, your only option is down-cloking the CPU

EDIT : I mean, the dpb system author could add cgroup support (and I could help him doing so since i've done something along these lines) yet I dont see any point doing so
 
steam proton, the fork of WINE for running win games on linux, has had a lot of hype. Can you see what happens with it on pyra?

Prob need hw acceleration before testing that though.
You'd also need something like ptitseb's box86 and it'd probably need to be extended to handle 64-bit instructions as well. Proton is designed to run x64 windows games on x64 linux, and there are other problems wrt. the pyra. It contains a library to convert directX calls into vulkan calls, and thus far the Pyra's CPU only supports openGLES (or full openGL 2.0 though gl4es also from ptitseb, based originally on code from lunixbochs).

Don't hold your breath in other words.
 
Middle mouse click as right double-click (i.e. left nub double-click)? Obviously not ideal, as it may be confusing when one accidentally double-clicks, but it may be workable.
 
The best one still is : cap the fps at 60 with vsync.

EDIT : I mean, the dpb system author could add cgroup support (and I could help him doing so since i've done something along these lines) yet I dont see any point doing so

It is a 5" LCD screen. ~24fps is likely good enough to be indistinguishable from any more. The rest winds up just creating heat.

The point is to get more hours of quality gaming/computing on half the battery while multitasking.
 
Middle mouse click as right double-click (i.e. left nub double-click)? Obviously not ideal, as it may be confusing when one accidentally double-clicks, but it may be workable.

Talking about that grench can you comment, do you often accidentily click the nubs or is the click very wel defined?
 
Those with prototypes: Hows the hinge?
Excellent. The only 'notch points' are at fully closed and fully open. Good smooth resistance end to end over the range in between. However, when using the stylus or touch-screen, count on needing to 'back it up' with a finger.
Post automatically merged:

Talking about that grench can you comment, do you often accidentily click the nubs or is the click very wel defined?
I hadn't actually 'clicked' the nubs before you asked (they don't actually do anything right now). It is well defined, requires a conscious effort, but does not feel too strong. They're good.

Do we have an input test program yet like we have for the Pandora where it shows the keys and nubs graphically and what they're doing on the screen? Maybe something simpler that just shows what keycodes are being generated?
 
Last edited:
Oh, and: I don't know how they're setup, but it could be possible that you can use them for MATE hotkeys.
And if MATE has a hotkey for the left / right mousebutton, you could even set that up there.
 
If screen size and frame rate (fps) had any relation, we could produce video with 5 fps for 1" size screen and 1 fps for even small screen ( which will be single image per second )

Actually, screen size makes a big difference in where the threshold for animation occurs.
From the page: https://en.wikipedia.org/wiki/Frame_rate

https://en.wikipedia.org/wiki/Frame_rate#/media/File:Animhorse.gif

You can just use ctrl +/- to resize the 12fps gif.
Sized down to about 2" it barely meets the threshold of animation, but your mind perceives it as animated.
Sized up to about 5" it appears quite choppy.
Sized up to 12" it's 'unwatchable'.
Games that will appear choppy as hell at 20fps on a 21" screen will be quite playable at 20fps on a 5" screen.

I would argue, then, that processing cycles being used to generate frame rates on a mobile device that are higher than 'needed' (admittedly variable on many factors) aren't doing any 'good' and are doing basic 'harm' to the experience by wasting battery power by turning it into heat without enhancing the user experience.

Where that threshold is will be variable on the user and the application/game being used. If we were to be able to put in a user configurable 'restriction' at the .dbp layer (so that it is application dependent), that would allow the device user to be able to adjust up/down how much CPU gets allocated to the application - which translates into a choice between battery life or frame rate - and would let the user choose where that balance best suits them.

That is the idea. I don't know if it is possible to implement. But, as is, 'greedy apps' will draw every scrap of CPU they can, regardless of whether doing so actually improves the perceived user experience.
 
Yep. Of course size/speed matters and also the screen response time. If ours is at least 16ms it will be able to render 60fps without blurring frames (imho).
 
Yep. Of course size/speed matters and also the screen response time. If ours is at least 16ms it will be able to render 60fps without blurring frames (imho).

Yes, screen response time matters in what the unit is -capable- of producing. I'm pretty sure the screen -can- do it, it is a very nice screen.

However, I argue, that even if it's able to produce 60fps, beyond being a spec number claim, there isn't much point to spending battery on CPU cycles for it when the difference between 30fps and 60fps on a 5" screen displaying sprite graphics is imperceptible.

Optimization on a battery operated handheld computer is about using as little battery as possible while giving the end user a solid experience. The Pyra is 'overpowered' for a lot of these games - that spend all available CPU cycles anyway - resulting in waste heat that doesn't add to the experience.
 
Back
Top