Gamescom, sensor upgrade and other nice news

[rSl]

I like the grey buttons against the red.

yeah, i too like this combination. it looks somehow oldskool but not boring, nice.

 

[ible]

hopefully ED can get the other 3 prototypes running with your kernel, @zmatt! thanks for the hard work!

 

[Caine]

@zmatt, impeccable timing. Great work!

 

[jonlad1]

Cant wait to see some videos of stuff running!

Is the Pyra hinge just going to work by friction as per the Pandora hinge?

 

[Exophase]

https://github.com/mvduin/linux/commits/patch/tiler-fbdev2
(Commits where I'm fully aware I'm doing horrible hacks just to "get it working first, do it properly later" have been marked with XXX.)

Does this mean fbdev is working okay on Pyra now? Last I saw it you couldn't allocate enough memory for two buffers or do panning. Never mind anything for the separate layers.

If it works like it does on Pandora that'd make it a lot easier to port between the two. I was anticipating needing to do a drm backend instead (at least until something is ready with OGL ES) but if I could just use fbdev that'd be a lot easier.

 

[EvilDragon]

It's been working for 17 hours already! Where have you been! ;-)
[doublepost=1471547583,1471546776][/doublepost]and it's even been packaged:
< aTc> apt-get install linux-image-4.7.0-letux-pyra-r+

Eh? I tried to follow IRC, but last thing I've seen was that it was working but crashes with fbturbo in X...?
Did you fix that?

Where can I grab a rootfs and the kernel for the Pyra...?[/QUOTE]

 

[directive0]

Cant wait to see some videos of stuff running!

Is the Pyra hinge just going to work by friction as per the Pandora hinge?

From what I recall yes; its basically the exact same hinge as the pandora... unfortunately (IMO).

 

[levi]

Where can I grab a rootfs and the kernel for the Pyra...?

If one is not forthcoming, you could build your own by installing the old rootfs, doing the apt-get install then tar archiving your rootfs, and copying your kernel off. But if you've got old units already working, I'd just to an apt-get upgrade then the apt-get install to get up to date quickly, rather than reflashing them.

Edit: Though I guess wifi might be spotty in the hall which is why a rootfs tar might still make sense.

 

[Letalis Sonus]

So I don't know about x86, but on the ARM SoCs I'm familiar with you're required to raise the voltage before increasing the clock and decrease the clock before you can lower the voltage. Clocking is definitely also a major power drain, but there's already extensive clock gating all over the place usually, and lowering the clock speed by itself obviously won't help if you still want to do the same stuff (hence just have less idle time)... unless it lets you lower voltage.

Of course clock and voltage interact with each other, but both can be changes to a certain degree without touching the other. I was referring to load-independent power consumption, an idle CPU doesn't save much with a lower clock if you don't lower the voltage as well - the CPU is being clocked down because it allows to drop the voltage further, the clock itself simply doesn't change much. There are just way too many who put the clock and power consumption into direct relation without considering the voltage.

 

[TrashyMG]

Played around with the new TILER enabled kernel, thanks to zmatt and aTc updating the Pyra Debian repo. Sorry for the audio static.

 

[zmatt]

Eh? I tried to follow IRC, but last thing I've seen was that it was working but crashes with fbturbo in X...?

That was 5 days ago

Did you fix that?

Yes, and it was celebrated 19 hours ago. You missed the party. There was cake. It was delicious.

Also I posted that I fixed the problem on the pyra kernel mailing list and cc'd you.

Where can I grab a rootfs and the kernel for the Pyra...?

rootfs no idea, same as before I guess? kernel has already been uploaded by aTc, see my previous post:

and it's even been packaged:
< aTc> apt-get install linux-image-4.7.0-letux-pyra-r+

 

[TrashyMG]

Another small video with more sideways goodness.

 

[EvilDragon]

Damn, I'm back at the hotel and Wifi is not working. Wanted to grab the kernel, rootfs and upload some pictures and video I took.
I guess I have to hope Wifi is working well tomorrow at the show!

 

[AnimatedFreak]

Went to Gamescom today, so made some pictures (didn't take many, so I can't spoil any fun for visitors).
The booth had a nice LED display powered by a raspberrypi showing PYRA with fire effects, looked really nice.
There were multiple devices around. Seen a GameGear with the LCD upgrade and everdrive, the screen is really clear compared to the original.
Also the GPD (Android) and Open Pandora were around.
On the main stage (table next tot the booth) there were the Pyra and the GPD-Win, the GPD-Win had an additional battery pack as it ran out of power (also the Pandora could charge the GPD-Win).

Multiple Pyra prototypes were available, the gray unit was most working one. It booted, (touch)screen/keyboard/nubs all worked. I didn't do to much, started a browser and clicked around a bit.
My first impression is it looked and felt sturdy. It also reminded me a lot about my Pandora, which isn't that weird, it was in a comfortable way. It's newer, but it hasn't change that much that you're lost. I bet you'll notice when you switch back to a Pandora and you're missing the new features.
The keyboard backlight worked nicely, I was wondering how much it would bother me but it actually didn't do that at all. At first I didn't know it was on, the keys were clearly readable (and there was enough light already). When making it darker you noticed the keys kept being clearly readable, which is a really nice feature. The keyboard also feels nice.
There also was a clear case Pyra, this one didn't boot though, but the case was a bit more tweaked I guess as the triggers felt better and the nubs were really smooth.

The GPD-Win was also available. First impression was that it looked more shiny, which looks a tat more sleek then the Pyra, and it felt a bit lighter. When holding it I noticed it was a bit warmer then the Pyra was (didn't notice any heat from Pyra btw).
Steam was open and I notice that was hard to read from the display, but you could configure font size if you would dislike this. I noticed as I could read clearly from the Pyra screen (the unit still had the discolorating touchscreen) but not from the GPD-Win, but I guess that's fixable as both devices have 720p screens.
The keyboard is default lay-out, which in my case makes stuff easy to find, but it's so cramped it makes it hard to type. The keys did feel plastic-like, but worked. The triggers felt really flimsy (big plastic buttons that react late), while the Pyra ones felt they reacted faster and has less travel.

When walking around I've also seen a booth with the Smach-Z, the unit is really big compare to the Pyra (or even a GameGear I guess). It worked, had full steam-like controllers on there and full-size triggers.
So if anyone is visiting the Gamescom and wonders if it even exists, there is a working prototype to view. When seeing a Pyra and GPD-Win the device is a bit less impressive, but never the less it's nice if there a more (working) portable handhelds in the world.

Additionally, I could play around with some VR stuff (which everyone has this year, not only the people producting them, so you can actually try them). The Vive was pretty nice, I didn't see myself waving/walking around (just like fist-time seeing a Wii) a controller, but the impression was good. Shame you have to have a cable to the headset, and you can hit other visitors (or in my case the guy from the booth) in the face without knowing.
The Oculus Rift, yes it was my first time trying it on (I did use other HMD before though), was easy to use a felt like a good product. I didn't expect to see pixels, but I did. I guess you don't care if the game is immersive enough. Even so it did look good, nice big field of view.
And I played with a Samsung VR set (the one were you click on a phone as VR). This one had issues for me, as you need to tweak the images to create the best field of depth, but from experience you need some time to get used to the setting which wasn't so for the OR/Vive.
[doublepost=1471478074,1471475689][/doublepost]Some pics:

The GPD-Win (you've seen the Pyra, right?)
View attachment 28923
Groupshot, my Pandora, the Pyra and the GPD-Win
View attachment 28924
Need some more power GPD-Win? Did you know you Pandora can be used as a charger?
View attachment 28925
From the top (the Pyra logo fell off)
View attachment 28926
Showing the ports on the back (Pandora/Pyra/GPDWin)
View attachment 28927

And a (very) short video:
[doublepost=1471478971][/doublepost]In case you ever wonder: Is it busy on Wednesdays?
This was the line when entering the north entrance at Kölnmesse for me today.
View attachment 28928

How did the nubs feel on the Pyra compared to the Pandoras?

 

[zmatt]

Does this mean fbdev is working okay on Pyra now?

Well, that depends a bit on what you mean. It doesn't really work more or less okay than before. (Okay maybe slightly less since I need to fix ywrap support for tiler-allocated buffers, but that only affects the performance of fbcon)

Last I saw it you couldn't allocate enough memory for two buffers

Well you could, just not via fbdev since omapdrm allocated a framebuffer of exactly width * height for fbdev.

As part of allocating the legacy fbdev framebuffer into tiled memory however, I was having some fights convincing fbdev to not throw kernel panics at me in the face of a discontiguous allocation, I just made it contiguous for now by widening the buffer to 8192 pixels.

For reasons that elude me right now I'm still telling userspace the virtual size is the (rotated) display size though... reverting commit 35952fb3eec969b1ef52bcdf2444a392444c4ce2 should fix that. At 1280x720 you'd then have space for 6 framebuffers side by side.

Oh right, the reason of course the buffer was never made larger than the display...

or do panning. Never mind anything for the separate layers.

While I'd have no trouble panning fbdev's framebuffer via drm (atomic modesetting), I'm not sure fbdev can do this. Haven't really done much with legacy fbdev stuff and only recently dug a bit into it as needed to get it working with tiler. Before that I just worked with drm. Thinking about it, I think it might be problematic to have fbdev panning work since from drm's point of view it's just a buffer. You could use drm to map different rectangles of the fbdev buffer onto display in different layers. I'm not sure what the driver would then be supposed to do with a request to "pan fbdev".

You can definitely not configure layers via legacy fbdev, this is purely done via drm now.

The bouncy translucent overlay you can see in TrashyMG's second video is actually some little test of mine to check the performance of scaling and moving a framebuffer around in a separate layer using atomic modesetting. (It worked perfectly at 60fps with negligible cpu load.)

If it works like it does on Pandora that'd make it a lot easier to port between the two. I was anticipating needing to do a drm backend instead (at least until something is ready with OGL ES) but if I could just use fbdev that'd be a lot easier.

Legacy fbdev compat is there for, well, compat. But it is very much legacy. The old pre-drm omapfb driver has been essentially unmaintained for years afaik, and all current graphics stuff from TI requires drm. E.g. fbdev support has been dropped entirely in the latest sgx drivers.

 

[Silent-Hunter]

@zmatt Thank you very much for fixing TILER and sharing the code!

 

[Shlee]

This news is glorious.

 

[Grench]

Damn, I'm back at the hotel and Wifi is not working. Wanted to grab the kernel, rootfs and upload some pictures and video I took.
I guess I have to hope Wifi is working well tomorrow at the show!

Hotel bar will have wifi. A bartender once bought me a round for explaining my Pandora to him...

 

[aTc]

Damn, I'm back at the hotel and Wifi is not working. Wanted to grab the kernel, rootfs and upload some pictures and video I took.
I guess I have to hope Wifi is working well tomorrow at the show!

You can find a rootfs with just about everything in it here: http://packages.pyra-handheld.com/images/extra/pyra-rootfs.img.xz
Download, extract, and dump it onto an 8GB or larger sd card ( same as you'd do for a rpi image )
It's based half on hns's makesd, half on my rootfs, and a bit of manual messing about.
I have no idea if this works at all, it's near impossible to test this stuff without having the actual hardware.

It should boot into the displaymanager, a user/password of pyra/pyra is set up (and root/root) , and should default to using the normal unrotated kernel.
To try the tiler version, mount the first partition on the card, edit uEnt.txt , and set bootfile=vmlinuz-4.7.0-letux-pyra-r+
You also have to disable the rotation chip stuff, which is the "./ssd2858 -r -p -s # start ssd" line in etc/X11/xinit/xserverrc

hardware 3d only works with the non-tiler kernel, and can be tested with "/opt/omap5-sgx-ddk-um-linux/bin/gles1test1 500". glshim is also installed.

 

[pyrat]

I have no idea if this works at all, it's near impossible to test this stuff without having the actual hardware.

Wow. ED's booth must be overcrowded. You get to watch new community software being tested on unique prototypes live in front of your very eyes...
I imagine people claping and cheering like in an sports match... I wonder why all TV stations are on the comparatively boring olympic games...
Maybe just feed this thread to that LED screen they say it's there ?

@zmatt, @aTc, @EvilDragon, all... thank you very much