Preparing for a Prototype

[Confuzzled]

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.

There are several mechanisms, of different utility and complexity. nice, cpulimit and cgroups. cgroups is a general resource controller which is complicated to set up, but has most flexibility.

Restricting process CPU usage using nice, cpulimit, and cgroups | Scout APM Blog

There are at least three ways in which you can control how much CPU time a process gets: use the nice command, cpulimit, or Linux's cgroups.

scoutapm.com

I recommend reading up on cgroups, because as well as enforcing relative cpu usage restrictions (e.g. one process gets twice as much as another if they are competing for the same thing), you can also set cpu usage ceilings with the cpu.cfs_period_us and cpu.cfs_quota_us ( https://access.redhat.com/documenta...ml/resource_management_guide/sec-cpu#sect-cfs ).

I don't know if the letux kernel offers the cgroups capability, and if so, whether it is V1 or V2.

 

[Silent-Hunter]

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.

Theorerically, ptitSeb's project Box86 could run Proton, but ptitSeb is not aiming to support WINE, so it may never work.

 

[sebt3]

I don't know if the letux kernel offers the cgroups capability, and if so, whether it is V1 or V2.

Since this is a debian, it has to, otherwise, systemd is very unhappy

 

[Grench]

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?

 

[sebt3]

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

 

[levi]

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.

 

[erico]

That would be very interesting!

 

[Haraldur]

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.

 

[Grench]

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.

 

[docbroke]

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 )

 

[erico]

Which makes me think...what is the response time of the Pyra screen? (And your order number?? )

 

[docbroke]

Which makes me think...what is the response time of the Pyra screen? (And your order number?? )

I don't know exact order number, but it surely above 1000.

 

[Bosbeetle]

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?

 

[λ the β-Redex Reducer]

Are the Fn buttons hardwired or can it be remapped like any other button using things like .Xmodmap?

 

[sebt3]

Are the Fn buttons hardwired or can it be remapped like any other button using things like .Xmodmap?

It's not hardwired. The current behavior is coded here : https://dev.pyra-handheld.com/packages/funkeymonkey-pyrainput/blob/master/pyrainput.cpp#L217
That comment mean that the mapping could be configured in /etc/pyrainput.cfg with a little more code...

 

[directive0]

Those with prototypes: Hows the hinge?

 

[Grench]

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: Jan 3, 2020

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?

 

[EvilDragon]

You can run evtest from the terminal.

 

[EvilDragon]

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.

 

[Grench]

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.