Parts, Boards and the Rotator

[sulu]

At least the Pyra screeen (and keyboard) brightness will be easily controlled. How it was envisioned during the keyboard discussions was pretty simple anyway.

To use the, "Brightness button" in the "Atic" area of the keyboard:
Push the brightness button = screen brightness increases.
Shift+brightness button = screen brightness decreases.
Fn+brightness button = keyboard backlight increases.
Fn+shift+brightness button = keyboard backlight decreases.

Don't panic - Fn and Shift should be easily chordable on the keyboard and/or the shoulder buttons.

I believe it would have been more intuitive to have dedicated keys for F11 and F12, and make brightness controls secondary and tertiary assignments of these keys.
But as long as the brightness assignments create regular keyboard events, it's pretty easy to remap them. It won't require any coding, only altering plain text files.

 

[ible]

the Keyboard Fn+Shift won't be easily chordable for the brightness key (since all those keys are on the right side of the keyboard), but that's ok because it will work with the shoulder modifiers. i suppose you can also reach across with the left thumb to hit the brightness key, though.

man that keyboard is a beauty!

 

[rygD]

At least the Pyra screeen (and keyboard) brightness will be easily controlled. How it was envisioned during the keyboard discussions was pretty simple anyway.
[Snip]

For me that will work fine. Most of the time I will need up to 3 screen settings (daytime indoors, and nighttime, with an occasional brighter one for daytime outdoors in direct sunlight). That is super easy with the keys, and if it rotates through all of those, then to off, and starts over, I will have everything I want. For the keyboard I only need an on and an off setting.

No flashy lights for me (maybe an occasional gently flickering flame on the back of the screen) but we might as well have fun with what we get.

I believe it would have been more intuitive to have dedicated keys for F11 and F12, and make brightness controls secondary and tertiary assignments of these keys.
But as long as the brightness assignments create regular keyboard events, it's pretty easy to remap them. It won't require any coding, only altering plain text files.

There was a lot of discussion and compromise, so we ended up with something that works ok but isn't perfect. The problem comes from individual preference and the limited number of keys. If we look at what one group prefers, then the other group will come up something that disregards the first group and only address the concerns of the second, and that just goes on and on. At some points one group did take priority (look at language support). The current layout should work for most people, even if there are some things that might be better differently on an individual basis or use case. Go look through the keyboard threads to see what I mean (and there was much more than you see done behind the scenes).

 

[Klumpen]

At least the Pyra screeen (and keyboard) brightness will be easily controlled. How it was envisioned during the keyboard discussions was pretty simple anyway.

To use the, "Brightness button" in the "Atic" area of the keyboard:
Push the brightness button = screen brightness increases.
Shift+brightness button = screen brightness decreases.
Fn+brightness button = keyboard backlight increases.
Fn+shift+brightness button = keyboard backlight decreases.

Don't panic - Fn and Shift should be easily chordable on the keyboard and/or the shoulder buttons.

I'm not sure who is going to write the control module for this in the OS/setup GUI, but a few whiz bang features could include:
"Continuous range" vs. "discrete values" options.
"Looping" when you hit the end of the range - max brightness for example, then release and re-press it could jump to 0 then work up again.
Pre-defined user jump-to-brightness settings for both display and keyboard backlight presets for Alt &/or Ctrl + brightness.

Frankly status LEDs and LED backlight controls for the keyboard and even the display for that matter shouldn't be that hard to address. Not like the dev team is going to hide how to systematically control them anyway.

If someone wanted to get funky they could write something to look like a pulse audio output device and have a dance club mode driven off of the sounds being generated - complete with it's own "volume" slider that would translate into brightness (and color on the status and lid LEDs).

Open devices are good for sillyness.

I think the best solution is taking advantage of the digital/analogue-hybrid volume wheel.
Hold a certain key for display or keyboard backlight, turn the wheel and Bob's your uncle.
Combinations of more than two things/buttons/keys are always awkward.

 

[levi]

The fancy wheel idea was killed off for me when somebody pointed out that if you pressed a key then spun it to increase brightness, when you let go the volume would shoot up and blow your ears off if you were wearing headphones. It's not a spinner, it's a potentiometer with defined end points, so it only really makes sense to me to use it as a single scale.

 

[comradekingu]

On the pandora yes, on the pyra, no. I dont know if its stopped at each end, that would make it awkward.

If it is a freewheel rotary encoder it can be done.

 

[Silent-Hunter]

On the pandora yes, on the pyra, no. I dont know if its stopped at each end, that would make it awkward.

If it is a freewheel rotary encoder it can be done.

It's not, it's a plain pot attached to an ADC.

 

[Neelix]

I also seem to recall ED saying that the volume wheel itself is actually exactly the same part that was used for the Pandora.

-Neelix

 

[WizardStan]

@EvilDragon Are you looking for a single large investor, or would people willing to invest just a couple of k€ also be welcome?

While I'm sure he would be genuinely happy with an investor, you should also be aware that this is a tongue-in-cheek reference to the PGS, and probably just a joke. He could probably use the investment, but it's not needed.

 

[zmatt]

Still curious how TILER's gonna do that with 0 performance impact. I'm all in for miracles but it doesn't want to sound plausible to me. Wouldn't it at the very least either block framebuffer access during rotation or need it's own copy of it?

TILER is integrated in the memory controller and operates directly on accesses to the framebuffer. Yoyobuae's explanation is largely accurate:

From what I understand, the TILER is a MMU trick. Data is shuffled as it read or written. Well, not the data but the address where the data is read/written.

Actually the data also needs to be rearranged.

So the TILER can implement a zero-copy rotation. The program only writes the data to memory once. The display driver only reads the data from memory once. The rotation happens in between either by using the TILER during the read or write. In theory, zero-cost rotation. If it works that is.

Oh it works It has worked all along, the issue was that the performance was abysmal. It turned out that this was due to how the driver set things up rather than being TILER's fault as such. Based on synthetic tests it looks like TILER's performance is perfectly adequate, but there are still some kernelspace things that need to be fixed before we can test real applications.

TILER is not actually "zero-cost" however. Access from the cortex-A15 through TILER is slower than directly to memory, mainly because the cortex-A15 has a special dedicated high-bandwidth low-latency connection directly to memory while access to TILER has to go over the main L3 interconnect. Also, the data reorganisation of TILER causes some memory bandwidth to be wasted when accessed by the cpu (if it writes linearly to the framebuffer). This however is a fairly cheap thing to waste as the memory has quite a lot of bandwidth, nearly 4 GB/s. For comparison, 1280x720 pixels * 60fps * 32-bit ≈ 211 MB/s. Tests so far seem to indicate it isn't hard to get write speeds to TILER around 700-750 MB/s which is far more than necessary or useful for Pyra's display.

For initiators that generate 2D bursts like the display subsystem and IVA-HD however TILER actually is free afaik.

 

[thatgui]

I also seem to recall ED saying that the volume wheel itself is actually exactly the same part that was used for the Pandora.

-Neelix

Are you sure - I thought the audio wheel as a digital output so the audio stack "knows" in which state/at which level the wheel is ?

Edit: Nevermind, ADCs are a thing for quite some time now

 

[sulu]

Go look through the keyboard threads

No! Thank you. I'm not a masochist.

 

[Neelix]

Are you sure - I thought the audio wheel as a digital output so the audio stack "knows" in which state/at which level the wheel is ?

Edit: Nevermind, ADCs are a thing for quite some time now

*nods* Don't forget that the prototypes actually have 2 sets of audio hardware for testing, one of those options involves using the volume wheel as an actual analogue control. The other has it hooked up to an ADC.

-Neelix

 

[pyrat]

Oh it works It has worked all along, the issue was that the performance was abysmal. It turned out that this was due to how the driver set things up rather than being TILER's fault as such. Based on synthetic tests it looks like TILER's performance is perfectly adequate, but there are still some kernelspace things that need to be fixed before we can test real applications.

Thanks for both your efforts and your explanations.

TILER is not actually "zero-cost" however. Access from the cortex-A15 through TILER is slower than directly to memory, mainly because the cortex-A15 has a special dedicated high-bandwidth low-latency connection directly to memory while access to TILER has to go over the main L3 interconnect. Also, the data reorganisation of TILER causes some memory bandwidth to be wasted when accessed by the cpu (if it writes linearly to the framebuffer). This however is a fairly cheap thing to waste as the memory has quite a lot of bandwidth, nearly 4 GB/s. For comparison, 1280x720 pixels * 60fps * 32-bit ≈ 211 MB/s. Tests so far seem to indicate it isn't hard to get write speeds to TILER around 700-750 MB/s which is far more than necessary or useful for Pyra's display.

Now it makes more sense. Rotated is slower than unrotated but not even near to too slow.
1920*1080*60*4=474.6MB/s << 700MB/s
Usually you don't have to rotate anything to output through HDMI out, but who knows, if you one day find a projector that can do 1080@60, is hanging upside down and doesn't have the option to rotate the picture (!?), you still should be able to output rotated video.
Or if a future LCD upgrades goes 1080p... (why?)
I think a more normal use case would be both the rotated pyra LCD and an external unrotated monitor. That doesn't look like it would need 60fps in both, but still, that's two different framebuffers, I guess...

For initiators that generate 2D bursts like the display subsystem and IVA-HD however TILER actually is free afaik.

I don't understand this last bit, but I feel somebody should need to explain me too many things here (or I should have to read up too much).
And it sounds good anyway.

 

[Jerommeke]

While I'm sure he would be genuinely happy with an investor, you should also be aware that this is a tongue-in-cheek reference to the PGS, and probably just a joke. He could probably use the investment, but it's not needed.

Missed that, I thaught he was being serious - i'm not really following the whole PGS thing.

 

[levi]

Thanks for both your efforts and your explanations.

I don't understand this last bit, but I feel somebody should need to explain me too many things here (or I should have to read up too much).

As far as I can tell it refers to subsystems within the OMAP chip that we're unlikely to be able to use for some time, so I wouldn't worry about it.

 

[EvilDragon]

Missed that, I thaught he was being serious - i'm not really following the whole PGS thing.

Yes, this is actually serious and I don't need one investor with 100K, it can also be a lot lower values.

 

[directive0]

How great would it be if you turned the Pyra into a co-operative. I'd definitely join above the money I've spent on a pre-order.

Also, ED, I hate to bother you I know you're busy but can you please release a video soon. Everyday I go on the internet its more stupid and terrible news about humans doing dumb stuff that's pointless and I'm boooooored. I want to go online and watch a video about the Pyra and share it with people so we can talk about something interesting instead of politics and economics and religion and all that stuff that really doesn't matter.

Help us ED, you're our only hope.

 

[Rockthesmurf]

I use auto-brightness on my phone, it is a Samsung Note 4, and on top of the auto-brightness there is a birghtness bar which basically means if the bar is set to the middle/default, the auto-brightness will just do its thing, using values it thinks makes most sense. But if you put the bar to minimum, it'll take their guessed values and pull them down, where as a bar at maximum will ensure the screen is always brighter than their guess. I certainly do not think auto-brightness is always great, and it isn't something I want on my Pyra, but I do find it good enough for the intended job on my Note 4. Every day I used my phone for about 50 minutes whilst walking, and during that time I go in out and out of shaded/sunny areas, and in that use case it can be somewhat useful. I don't imagine many people would have this same behaviour with their Pyra (in fact not many people even do it with their mobile!).

 

[Yoyobuae]

TILER is not actually "zero-cost" however. Access from the cortex-A15 through TILER is slower than directly to memory, mainly because the cortex-A15 has a special dedicated high-bandwidth low-latency connection directly to memory while access to TILER has to go over the main L3 interconnect. Also, the data reorganisation of TILER causes some memory bandwidth to be wasted when accessed by the cpu (if it writes linearly to the framebuffer). This however is a fairly cheap thing to waste as the memory has quite a lot of bandwidth, nearly 4 GB/s. For comparison, 1280x720 pixels * 60fps * 32-bit ≈ 211 MB/s. Tests so far seem to indicate it isn't hard to get write speeds to TILER around 700-750 MB/s which is far more than necessary or useful for Pyra's display.

I knew I was probably missing some details, I just tried to get the point across that the TILER is more efficient than copying to a buffer first and then rotating the data.