If there is a horizontal menu, the experience will be much exhanced.
coffeeken
All 4 comments
If there was touch support yes. But touch support is a no for hekate, because of size constraints (we need to upload the touchpanel's firmware in every boot and if we want real UX, we have to include it in the payload binary).
Otherwise the UX is regressed by having to press the volume buttons in 90o degrees orientation.
Additionally, a horizontal menu, as much as I want to do it, it can degrade performance and also reach size limits.
EDIT:
Additionally, having the touchscreen firmware distributed like this, is probably illegal.
CTCaer
on 9 Jul 2018
Why would it degrade performance? All you need to do is calculate coordinates slightly different. You can dirty render over the previous screen instead of refreshing the whole display, and the only performance hit should be when scrolling occurs due to needing lines memcpys of size (yaw - bpp) rather than (lines-1)*yaw memcpys for the whole yaw. I haven't read the code, but I'm assuming you're working with a 720x1280 framebuffer. Even then, both are slow without hardware assistance. It shouldn't be that different. Just avoid scrolling.
People have to deal with the volume button mapping thing on many phone-like android devices and tablets. It's generally accepted that the left button is up while the right is down if the buttons are on the top of the device, and the reverse otherwise.
For touchscreen firmware - I don't think that's what this report is really about. It's about the inconvenience of the ninety degree angle. I personally would just require users to provide it for touchscreen to be used.
chaoskagami
on 11 Jul 2018
Could you not load the touchscreen firmware from eMMC? Horizon should store it somewhere after all.
mologie
on 12 Jul 2018
Closing in favor of https://github.com/CTCaer/hekate/issues/65
CTCaer
on 7 Aug 2018
Related issues
ollidiemaus
路
9Comments
aveao
路
6Comments
Goma1337
路
6Comments
tegutistgut
路
3Comments
Myselfs-s
路
3Comments
Most helpful comment
Why would it degrade performance? All you need to do is calculate coordinates slightly different. You can dirty render over the previous screen instead of refreshing the whole display, and the only performance hit should be when scrolling occurs due to needing lines memcpys of size (yaw - bpp) rather than (lines-1)*yaw memcpys for the whole yaw. I haven't read the code, but I'm assuming you're working with a 720x1280 framebuffer. Even then, both are slow without hardware assistance. It shouldn't be that different. Just avoid scrolling.
People have to deal with the volume button mapping thing on many phone-like android devices and tablets. It's generally accepted that the left button is up while the right is down if the buttons are on the top of the device, and the reverse otherwise.
For touchscreen firmware - I don't think that's what this report is really about. It's about the inconvenience of the ninety degree angle. I personally would just require users to provide it for touchscreen to be used.