Beauty competition.

[TrashyMG]

@ptitSeb, wondering if that was the case seeing the movement on the kernel mailing list. Good to see, feel a little out of the loop since I can't get on IRC much or at all lately...

 

[rSl]

So @daveshah as made a patch to make 3D Driver compatible with @zmatt Tiler code.

awesome news, thanks!

 

[Phlyra]

So @daveshah as made a patch to make 3D Driver compatible with @zmatt Tiler code. It's a bit manual for now, but will improve quickly and @aTc is planning to integrates all this in the firmware.

And it works

View attachment 36143

View attachment 36144

Only picture, so you don't know if it's smooth...

But yeah, my short session on Bit.Trip.Beat was smooth and nice (playing with the nubs...).
I may try some video later...

Damn that looks awesome!

 

[matzesu]

Cool, so this means there is a good chance for N64, PS1, Dreamcast etc on the Pyra??

Nice to see this issue was solved


Whit best regards, Matthias

 

[daveshah]

It can't do N64, PS1 or Dreamcast. Where do you think the cartridge or disk would go?

 

[matzesu]

As a Image on the SD Card on a Emulator on the Pyra, but whiteout 3D Driver, it’s quite though to Port a Emulator


Whit best regards, Matthias

 

[Silent-Hunter]

It can't do N64, PS1 or Dreamcast. Where do you think the cartridge or disk would go?

For the latter two, I have an external DVD drive!

 

[sm0kew0n]

@ptitSeb Is that FTL via Box86?

 

[TrashyMG]

It can't do N64, PS1 or Dreamcast. Where do you think the cartridge or disk would go?

For the latter two, I have an external DVD drive!

For the former I have the Retrode 2 with N64 adapter.

 

[Grench]

So, how long until we can be at a point where I can install Supertux on it?

Great news! I have been looking forward to this.

 

[ptitSeb]

@ptitSeb Is that FTL via Box86?

Yes it is.

 

[daveshah]

So, how long until we can be at a point where I can install Supertux on it?

Great news! I have been looking forward to this.

Supertux was actually one of my test cases!

 

[crazyhorse]

2 more weeks TM

 

[docbroke]

So @daveshah as made a patch to make 3D Driver compatible with @zmatt Tiler code. It's a bit manual for now, but will improve quickly and @aTc is planning to integrates all this in the firmware.

And it works

View attachment 36143

View attachment 36144

Only picture, so you don't know if it's smooth...

But yeah, my short session on Bit.Trip.Beat was smooth and nice (playing with the nubs...).
I may try some video later...

Software is getting better, this is great news. I guess by the time pyra is released, software will be ready for day to day use.
Does this patch also correct the issue of rotated display when output from HDMI ?

 

[levi]

Does this patch also correct the issue of rotated display when output from HDMI ?

The way I read it @daveshah was speculating that it would when he posted the diffs to the mailing list. I'd also second someone with a prototype actually testing that out.

 

[docbroke]

The way I read it @daveshah was speculating that it would when he posted the diffs to the mailing list. I'd also second someone with a prototype actually testing that out.

Yeh, I read that on mailing list. As I understood it; daveshah used hdmi output to look at the tiler problem ( as he is not having lcd display for his omap5 devboard), and his patch solved the issue with 3d driver not working with tiler code.
On re-reading I am happy to see that he was able to rotate hdmi display using command line, so this can be solved manually at least. I am quite interested to know which command helped there, AFAIK xrandr is not supported in pyra.

 

[daveshah]

I was using the KMS kernel command line to configure rotation, adding rotate=90 to the end of the video= line for HDMI. This defaults to 0 if not messed with, so HDMI should be unrotated, whereas the LCD has a hardcoded panel orientation now so will always be rotated unless overriden. The bigger problem with HDMI output is likely to be how the current framebuffer and X11 configuration handles multiple displays in general.

 

[ptitSeb]

Here a short comparison video with Unreal Flyby


Sound is so weak, I messed up something, anyway, it was about the picture, not the sound...

 

[docbroke]

I was using the KMS kernel command line to configure rotation, adding rotate=90 to the end of the video= line for HDMI. This defaults to 0 if not messed with, so HDMI should be unrotated, whereas the LCD has a hardcoded panel orientation now so will always be rotated unless overriden. The bigger problem with HDMI output is likely to be how the current framebuffer and X11 configuration handles multiple displays in general.

Does that mean display rotation change will not work on the fly but will require reboot ? I guess we can have different rotation settings for lcd and hdmi configured in KMS mode line so that we get proper display rotation with both in built lcd and external monitors without having to choose correct orientation in one of the either.
I really hoped for shell command when you said command line.

EDIT: I wrongly quoted my own post, now corrected.

 

[daveshah]

Yes, the orientation is per-display, so most of the time it should never need to be changed from the default - HDMI not rotated, LCD rotated 270°. There is no particular reason why it can't be done on the fly too, but I'm not sure if anything currently exposes it at runtime to userspace so some extra small program might be needed.