Pyra Gitlab access

[ToastBucket]

Heyo. I’ve been seeing some stuff lately about some crucial things that still need to be done on the low level Pyra software and not enough devs to do it. The things which seem most crucial appear to be in the bootloader and kernel drivers.

I’ve got some experience doing board bringup for these kinds of devices and I’d like to help! I know that there’s not much of a chance of me getting some hardware to work with any time soon, but I could create some pull requests and someone with hardware could test it out when they get a chance.

I found that there is a DBP gitlab, but appears empty. If my help is wanted, am I able to get some basic access from a dev (to pull and push a dev branch) to gitlab (or whatever git remote is being used) for the kernel and bootloader?

I messaged ED already, but I know he’s quite busy traveling the last couple days, so figured I’d reach out to the whole community.

 

[pimaster]

https://dev.pyra-handheld.com/packages/dbp doesn't look empty to me. I can't remember if the repo uses the same credentials as the forum or if you have to sign up again.
Have you found the OS repo at https://projects.goldelico.com/projects/ ? Apparently that should run on a Raspberry Pi 3B+ if you are looking at some hardware to run. You'll be missing out on the joys of TILER though.

I was contemplating how much work would have to go into opening up the omap dev board to external people. I guess I'd have to segment my network.

 

[ToastBucket]

I was contemplating how much work would have to go into opening up the omap dev board to external people. I guess I'd have to segment my network.

I have access to OMAP5432 devkits so I could potentially boot on there. Depends how far they stray with Pyra hardware. But it definitely wouldn’t help too much as the things which need work (other than 3D) would be unavailable on the dev kit. However, the xorg issues could potentially be flushed out.

 

[pimaster]

There are definitely some limitations to what you can do. Battery, sound, volume wheel and additional inputs are probably out.
I can get Firefox working with the install from https://projects.goldelico.com/p/gta04-makesd/ but when I compile the kernel myself and use the image from https://packages.pyra-handheld.com/images/stretch/ Firefox and Chromium fail to launch. When I last looked at it there were several issues floating around that it was a known issue with the armhf builds. The other night I was looking at building chromium myself but that is another giant rabbit hole I could go down as I couldn't get it working out of the box.

3D and rotation are definitely something that should be able to be worked on with the devkit. My understanding is that the processing of a screen is handled independently of how it is exported (HDMI, MIPI, DISPC and RFBI)

 

[levi]

My understanding is that the processing of a screen is handled independently of how it is exported (HDMI, MIPI, DISPC and RFBI)

Does that suggest we'll be limited to 720p output if using the internal screen at the same time as the hdmi output and mirroring it? On the Pandora we could certainly define a discrete framebuffer for the TV out, becuase I remember DraStic using it putting the top screen on the TV and the bottom screen on the Pandora's screen.

To be honest, I've never really known what to expect if mirroring and yet putting out 1080p on the hdmi. A cropped framebuffer locally, or some kind of scaling arrangement?

 

[pimaster]

I don't think the limitation is a pyra thing, but a mirroring thing. If you mirror one 720p screen, it'll be 720p on the other. Could you imagine a webpage being rendered on the built in screen at 720p then magically re-rendered at 1080p on the other? Wouldn't happen.

 

[ClockworkCoder]

Could you imagine a webpage being rendered on the built in screen at 720p then magically re-rendered at 1080p on the other

Actually, yes. Lots of websites are built specifically to scale exactly independant of resolution.

Scaling a screen is admittedly different, unless the target was 1080p and the other screen scaled down.

 

[EvilDragon]

Every normal PC (be it Windows or Linux) I know has the same internal resolution when you mirror a screen.
Only scaling is possible, so you could either use a 720p as resolution and scale it to 1080p or use a 1080p resolution and scale it down to 720p for the second screen.

If you want different resolutions, you need to extend the desktop.

 

[Letalis Sonus]

At least as far as Linux and X is concerned you can also set up the smaller screen to simply show a part of the larger screen, which is even able to move with the mouse cursor when you hit its boundaries.

 

[pimaster]

Actually, yes. Lots of websites are built specifically to scale exactly independant of resolution.

Yes, a webpage can be rendered at different resolutions, like 1080 OR 720. But can a single process render 1080 AND 720 at the same time since it is meant to be "mirrored". No (as others have mentioned).
Could it still be considered mirroring if the browser was able to apply different media queries and the page looked different on screen A vs screen B? When you click the mouse, does it take the position of screen A or screen B?

 

[EvilDragon]

At least as far as Linux and X is concerned you can also set up the smaller screen to simply show a part of the larger screen, which is even able to move with the mouse cursor when you hit its boundaries.

Ah, true, that's another possibility where it still uses the same internal resolution