Got displays, looking for keymats


Then the further query of how it is Android achieves rotation, and can we not do the same... leading to the general acceptance of Ed's initial proposal.
Android uses the 3D driver (GPU) for everything, also the rotation.

In theory we could do the same (Wayland does this), but this would mean that we constantly use the 3D driver, which would inrease the power consumption quite a bit and reduce the battery time.
 
Then the further query of how it is Android achieves rotation, and can we not do the same... leading to the general acceptance of Ed's initial proposal.
Android uses the 3D driver (GPU) for everything, also the rotation.
In theory we could do the same (Wayland does this), but this would mean that we constantly use the 3D driver, which would inrease the power consumption quite a bit and reduce the battery time.
this is why the rotation chip is good. :) I enjoy my battery life. Can't wait for more information end.

Sent from my Z665C using Tapatalk
 
Wouldn't using the GPU for rotation worsen performance for things like OGL games?

Also, GPU drivers tend to be buggy and unsatisfactory - not something you'd want to rely on in a hacker-friendly device.
 
With regard to the shoulder button discussion, instead of having 4 shoulder buttons either stacked or side-by-side, what about using 2 dual-axis buttons so pushing the shoulder button in from the back is L1 / R1, and pushing in from the side is L2 / R2?

To push both at the same time, you would just push diagonally in from the corner, which could even be slightly flattened to provide more of a pushing surface.

Thoughts?
 
With regard to the shoulder button discussion, instead of having 4 shoulder buttons either stacked or side-by-side, what about using 2 dual-axis buttons so pushing the shoulder button in from the back is L1 / R1, and pushing in from the side is L2 / R2?


To push both at the same time, you would just push diagonally in from the corner, which could even be slightly flattened to provide more of a pushing surface.


Thoughts?
:unsure: just from reading that and the fact I look forward to the shoulders being used for keys for typing ( shift control, function, a dead key or compose like function... or even having them be fully rebindable.) I for see a lot of accidental screw ups with that Z no don't don't undo that sentence! Argh.. or clicking both at the same time.

Sent from my Z665C using Tapatalk
 
Ok, I should have been more specific... Ed's explanation of why due to the popularity of smartphones, all screens available in the size we want are portrait.
I don't think there really is such a thing as a "portrait" or "landscape" screen. The screen just displays pixels sent from the video adapter (graphics card in a PC), so it's up to said adapter to sent the pixels out in a certain pattern, is it not? Hell, most PC video cards even expose the ability to rotate the screen via their control applets.

I assume the chip ED has been mentioning is just correcting (moving the pixels effectively by 90 degrees) the output from the video adapter (which I assume is part of the SoC and not separate/discrete component) and that said adapter cannot do it on it's own? Are these video adapters really so locked into one natural orientation that can't be changed at the firmware level or so?
 
Ok, I should have been more specific... Ed's explanation of why due to the popularity of smartphones, all screens available in the size we want are portrait.
I don't think there really is such a thing as a "portrait" or "landscape" screen. The screen just displays pixels sent from the video adapter (graphics card in a PC), so it's up to said adapter to sent the pixels out in a certain pattern, is it not? Hell, most PC video cards even expose the ability to rotate the screen via their control applets.

I assume the chip ED has been mentioning is just correcting (moving the pixels effectively by 90 degrees) the output from the video adapter (which I assume is part of the SoC and not separate/discrete component) and that said adapter cannot do it on it's own? Are these video adapters really so locked into one natural orientation that can't be changed at the firmware level or so?
The problem is that image data is usually stored in memory in the same pattern that the screen expects to receive, so the transfer to the screen becomes a simple copy operation. Anything more complex than a simple copy operation would require the use of memory bandwidth or GPU or something (ie. rotation chip). I don't know, but maybe those PC video cards have functionality similar to the rotation chip included.

Another way is to have all programs output image data in the "correct" orientation, which can be done for X based programs, but not for ones which use direct framebuffer access.
 
Last edited by a moderator:
PC video cards generally take over responsibility of rendering the display to VGA/HDMI/DVI etc, so programs are used to telling it what to draw and letting it do it. That means the card can choose to rotate it and send the pixels out in a different way to how the CPU rendered them using its GPU pipelines. Using an increasingly general-purpose GPU for that is a little wasteful, but we're generally not that concerned about that sort of thing, even on laptops where people are used to big batteries and short run times.


Android apparently does something similar, but it doesn't quite work the same way AIUI, as the GPU is not responsible for rasterising and rendering graphics on ARM platforms - it instead takes the bitmap data in memory, fiddles with it and writes it back. That's more powerful, as the CPU can then access the result if it wants, less wasteful, as it doesn't require its own bank of RAM, but uses up memory bandwidth in both reading and writing to RAM.


As I understand it, this rotation chip solution is a little like the x86 PC solution, in that it pulls bitmap data from memory and renders the output to HDMI/Mipi, possibly rotated, colour corrected etc. It doesn't maintain its own framebuffer like PC GPUs though, and is less general purpose, so it's less expensive to run. It does mean we can't pull values out of the display end of it, I think, but given the simple nature of the transforms the chip does, we probably don't lose too much doing that.
 
I though the rotation chip was placed "inline" between the SoC and the LCD, ie. takes MIPI input and generates MIPI output (to the SoC the rotation chip appears like a display).
 
I though the rotation chip was placed "inline" between the SoC and the LCD, ie. takes MIPI input and generates MIPI output (to the SoC the rotation chip appears like a display).
That's also what I know.

And because of the fact that the chip is like a display that supports different resolutions we can use XrandR like on a common Display.
 
Sorry, yes. I don't know that the chip has a memory interface. It may require the chipset to render that to Mipi first, but it doesn't really affect the data flow either way.
 
I'm looking out for the person that will ask the same question as we do but in a year (or even later) or so.
There is so much discussion about the Pyra, it's probably the only product I know that is reviewed so well.
Slap the forum topics on a CD and probably all the answers to your questions are in there.

And the idea DrHAX has about the buttons, I sounds great but I already having issues with stuff on the side of my PSP; so I would probably not like the trigger buttons on the side.
On my PSP it's because you have to hold the device, and when you are really into a game you do not pay to much attention and just hold your device. You don't want to tap any buttons by accident (or in my case shutdown my PSP, argh!). Maybe people will hold the Pyra differently so I won't matter.
 
I'm looking out for the person that will ask the same question as we do but in a year (or even later) or so.


There is so much discussion about the Pyra, it's probably the only product I know that is reviewed so well.


Slap the forum topics on a CD and probably all the answers to your questions are in there.


And the idea DrHAX has about the buttons, I sounds great but I already having issues with stuff on the side of my PSP; so I would probably not like the trigger buttons on the side.


On my PSP it's because you have to hold the device, and when you are really into a game you do not pay to much attention and just hold your device. You don't want to tap any buttons by accident (or in my case shutdown my PSP, argh!). Maybe people will hold the Pyra differently so I won't matter.
I've only accidently pressed my shoulders on the Pandora when I have to move it when typing... usually lying in bed.. or getting really into an action scene I'm writing :lol: But the four shoulder buttons are going to be there... honestly my idea was just what I've seen done from a... Satek? Joy pad.. that said joy pad has been disassembled and turned into a midi controller.. I found one with a turbo button to use instead for gaming :D

still I've dissassembled many controllers.. and that one had the simplest layout... and the most effective .. two tiny PCBs attached with wire soddered to the main board.


I was also thinking maybe the PCB could be made with the shoulder button PCBs on but in a purposable break away fashion. With the wires already soddered on... I don't know if this would be possible but its a thought.


Sent from my Z665C using Tapatalk
 
Having the shoulder buttons on isolated mini boards might be an interesting idea worth investigating. Space is pretty tight there between the case corner/buttons and the speakers but being able to use flat mounted buttons on a vertically mounted board might save space over the current right-angled buttons, and be a bit more robust.


Personally I think the solution to making them more robust against drops is to not have the button wrap over the bottom edge. It does mean you have to pay more attention to tolerances and gaps so that the button doesn't foul on the case all around it now, but that'll be the case for the top shoulder buttons anyway. It should mean that even if dropped on an unyeilding flat surface like concrete, the surface can't force the button in any further than it's normally meant to go before fouling the case itself, although momentum may exert a further force on the button. I'd hope the small momentum a plastic button in isolation is going to have can easily be resisted by the hardware even at the velocity of a Pyra dropped around 1m, whatever that is.
 
Ok, you must have missed the whole discussion regarding finding a suitable screen...

=~. O =
No I didn't. My point was: Because of the way Android handles rotation (which I happen to know) there is no difference between an android 5" phone or a 5" tablet, they can both work with portrait or landscape because they can rotate everything they display anyway. The only difference is what you "call" it.
 
Back
Top