Production Pyra photos/videos/thoughts thread

[Confuzzled]

Everybody wants something different I’m working to make this customizable via the uEnv.txt file so you can configure the behavior however you want. To start it will be hardcoded to a particular management loop but I will working on making it configurable soon after.

Ah well, I only made a suggestion. I can well understand that some would prefer a rainbow of colours, or even just red/orange/green. Technically, it would be possible to combine both approaches e.g. fast-flashing red, slow-blinking orange, steady green. Customisable sounds good. Frankly, just a single LED indicating the battery is connected to a powered charging source would be enough: the rest is just decoration.

(I once had a Dell laptop that had 5 LEDs on the battery. A press on a button lit up the LEDs as a crude bar-chart indicating the state of charge of the battery, which was useful when juggling multiple batteries - you didn't need to put the battery into a laptop and boot it up just to see how much charge was available. I am NOT suggesting this for the Pyra batteries.)

 

[hns]

Also, it should be noted I identified a hardware bug a few days ago that prevents software control of the red line in the center LED. ... It should be able to be disabled via a GPIO, but due to the hardware bug it cannot be.

Well done for finding the hardware bug!

Well, it is not really a hardware bug but a limitation. It was not designed to work this way, so it doesn't work... IMHO it is only a weak limitation for full configurability. There is also a similar limitation for the left and right LEDs which are connected to the USB host overload detector. And, one LED in the display lid remains illuminated after a cold boot until the OMAP turns it actively off. So if the OMAP doesn't boot or gets stuck for any reason during boot you will still see that the Pyra is still powered on and draining the battery. Then you can press the power button for 10 seconds to force shutdown.

 

[matzesu]

This is actually a good solution, its a feature not a bug,
I noticed yesterday when i dit my small test video, that my Pandora was still on when i opend the lid part, it meantioned that it was not properly power off the last time.., so it runs the whole week or so..
I had my LEDs settup on the Pandora to not glow whyle the Pandora is in Low Power Mode..

 

[hns]

Is FN mappable for scripts?

Depends on what kernel and user-space tools are doing with the key events.
Here is a description of how the keyboard is mapped to hardware: https://www.pyra-handheld.com/wiki/index.php?title=File:PyraKeymatAndButtonsFunctions.png

Post automatically merged: Sep 2, 2020

cool!

So does that mean when you use i2cdetect the LED Controller shows up there?

Well, no. i2cdetect will report "UU" because there is a kernel driver which maps the LEDs to /sys/class/leds.
But yes, if you unload the drivers you can use i2cset to control the LEDs. i2cget will not report anything since the chips are write-only.
So it is better and easier to use the kernel driver...

 

[docbroke]

Here is a description of how the keyboard is mapped to hardware: https://www.pyra-handheld.com/wiki/index.php?title=File:PyraKeymatAndButtonsFunctions.png

That keymap image looks outdated, there is pause in place of user key, and there are two brightness keys in place of one.

 

[ToastBucket]

Well, no. i2cdetect will report "UU" because there is a kernel driver which maps the LEDs to /sys/class/leds.
But yes, if you unload the drivers you can use i2cset to control the LEDs. i2cget will not report anything since the chips are write-only.
So it is better and easier to use the kernel driver...

Yes i2cdetect will report that it is grabbed by a kernel driver but you can still use i2ctools to communicate with it, you just will likely interfere with the kernel driver so it is highly not recommended.

 

[ToastBucket]

Well, it is not really a hardware bug but a limitation. It was not designed to work this way, so it doesn't work... IMHO it is only a weak limitation for full configurability. There is also a similar limitation for the left and right LEDs which are connected to the USB host overload detector.

From the schematic, I thought it was designed to allow reading the CHG_STAT line from the bq24 using the GPIO as an input, or driving the GPIO high to prevent the current flow through the diode into the CHG_STAT input to the bq24 for full software control of that LED. From the look of the bq24 datasheet, this should be safe with that pin (open collector no pull) but you designed the hardware so I don’t know your intentions. Either way, it is safe from a hardware standpoint and I just need to find a sensible way to manage this LED so that the behavior feels natural. Of course if anyone disagrees with my decisions of managing it, the source code is available and recommendations/merge requests will be welcome.

 

[PowerGod]

I like the fact to be able to see some important hardware statuses from LEDs even when the software is not doing its job.

 

[λ the β-Redex Reducer]

Here is a description of how the keyboard is mapped to hardware: https://www.pyra-handheld.com/wiki/index.php?title=File:PyraKeymatAndButtonsFunctions.png

Right click is left and left click is right.

 

[hns]

Right click is left and left click is right.

Yes, you are right (or left?)...
It is ca. 5 years old description (done before some keyboard discussion threads did appear here
But it is a Wiki page and open for updates.

 

[levi]

Right click is left and left click is right.

Yes. Do you have a problem with that? The idea was you can scroll with the left nub and even click and drag still using the left nub while holding down the right nub. I'm not sure what out of that idea has persisted into the prototypes, and if it's really all that newbie friendly, but that's the reason for it I think.

 

[pmprog]

I thought adding the two smaller buttons next to the gamepad buttons were going to be setup as the mouse buttons? Or at least configurable as the mouse buttons... Obviously they'd be better suited as keys when using an emulator that has a 6 face button controller (Megadrive, or Street Fighter 2+)

 

[λ the β-Redex Reducer]

Yes. Do you have a problem with that? The idea was you can scroll with the left nub and even click and drag still using the left nub while holding down the right nub. I'm not sure what out of that idea has persisted into the prototypes, and if it's really all that newbie friendly, but that's the reason for it I think.

Can the button not be clicked while moving with the circle-pad?

 

[Blue Shadow]

Can the button not be clicked while moving with the circle-pad?

Not sure about that, but even if possible, I would assume to loose quite a bit of precision while doing that, at least the ones who already haven't the best fine motor skills.

 

[levi]

No, and that's why this solution was come up with. I believe I've been told that the nubs are only designed the be clicked when in the centre.

 

[docbroke]

AFAIK from recent discussions, left nub moves the mouse curser and moving right nub to left or right emulates mouse click of respective side. Clicking the nubs is not configured. Up and down movement of right nub works like scroll wheel.
The reason for not using left nub for left click is to allow dragging windows with left nub while holding right nub in left position.

 

[λ the β-Redex Reducer]

AFAIK from recent discussions, left nub moves the mouse curser and moving right nub to left or right emulates mouse click of respective side. Clicking the nubs is not configured. Up and down movement of right nub works like scroll wheel.
The reason for not using left nub for left click is to allow dragging windows with left nub while holding right nub in left position.

That's a much better solution. That way the middle button & scrolling wheel could be configured to be activated by moving the right circle-pad up or down or clicking it.

 

[levi]

AFAIK from recent discussions, left nub moves the mouse curser and moving right nub to left or right emulates mouse click of respective side. Clicking the nubs is not configured. Up and down movement of right nub works like scroll wheel.

That's how the Pandora nubs worked, except there was no scroll wheel. Up acted like a double click, and down wasn't mapped to anything.

If you remove double click and put in the scroll wheel functionality where that was, does that not make it hard to double click? You end up needing to move left then return the spring to the middle and do it again; I found it doable when I tried it, but far less reliable than using the built in double click feature.

 

[Grench]

Right now we have a temporary solution where the right mouse left / right does left / right mouse click. Yes, I know this is how it is / was on the Pandora. Yes it was a compromise back then and still is.

Left nub = mouse movement.
Having the left nub click = right mouse click enables pulling up contextual menus wherever the mouse is at that moment.
Having the right nub click = select / drag / left mouse click should be a substantial improvement over what the Pandora uses now. Why? Because it frees up that right analog nub from being relegated to binary clicks.
Right nub = scroll. Because it is analog, you don't just have single speed scroll, but variable speed scroll in all four directions. The implications of this on a small screen handheld device are -huge-. It effectively means you can define a desktop in 4K pixels and whiz around the screen - or have your web browser zoomed in on a page and be able to both fly and crawl and anything in between left / right / up / down through content.

So, folks, please quit trying to destroy the interface potential of the Pyra through campaigning to have that beautiful right analog nub relegated to dumb mouse clicks like the Pandora had? That is why the nubs themselves have press-click features. At this point the hardware to make the interface 'right' is there and we're pending the software side to catch up.

 

[Pickle]

if any of the people with units want to try quake 1 source with GLES I have it here:
pickle.gp2x.de/glquake-src.zip

i recommend yquake2 also:

GitHub - yquake2/yquake2: The Yamagi Quake II client

The Yamagi Quake II client. Contribute to yquake2/yquake2 development by creating an account on GitHub.

github.com

it works well with gl4es but i think should have GLES option.

Pitiseb had a quake3 version, it doesnt take much to port to GLES.

there were 2 ways (X11 or FB) to interface with the SGX driver on pandora. We ended up primarily using the frame buffer way since the latest drivers broke with X11.
But this might not have been such a bad thing since it might have helped with latency of rendering.
I honestly am a little concerned using the composite route if that eats up some performance, but maybe its fast enough on this hardware. Also concerned TI does the same thing again and breaks the software stack (DRI)