Silent-Hunter
Hardcore Member
- Joined
- May 29, 2010
- Messages
- 3,485
I did. I was wondering why everyone was still talking about it.
Pictures, Videos and thoughts of a Pyra dev-prototype
- Thread starter ptitSeb
- Start date
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
I've never read anything you've posted. Ever.
And AFAIK it has debug symbols enabled right now. I think the first 15-20 seconds are just the bootmenu and the kernel. It should be able to boot into desktop in about 10-15 seconds when properly optimized.
So yep, right now it's slow
Sent from my XT1650-03 using Tapatalk
So yep, right now it's slow
Sent from my XT1650-03 using Tapatalk
Caine
Hardcore Member
Cool. That sounds quite promising in terms of being able to trim off some seconds.
AndiTheBest
Active Member
And emmc will be faster than uSD i think.
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
Which brings up more questions...
Why are the prototype units being booted from SDXC?
Have there been any successful boots from the eMMC or microSDXC?
Is the eMMC and/or microSDXC visible to the OS booted from on the SDXC?
I recall that the left and right SDXC run on different internal methods. Are both visible to the OS now or is that still pending software development?
levi
Still fresh, damnit!
To answer the first question, I think that devs are still using SD cards to boot from because the OS will need to be reflashed frequently at this stage. They might even have a pair of cards so they can be setting one up while continuing to work on the other. Your other questions are valid, and the answers should be interesting, but I don't have a prototype unit so can't answer myself.
I did the sunlight test:
Bright (really bright) sunlight coming from behind:
Pyra, Pandora and my Phone (Blackberry Priv): I see absolutely nothing.
At full brightness even comparing the glossy Pyra screen with the good old mate Pandora screen the Pyra got slightly better results.
Especially with White background/black letters (I use it the other way round normally).
The Pyra screen can be both, a lot brighter and darker than the Pandora screen.
I appreciate later as well, as it is a lot more eye friendly in dark environments.
Bright (really bright) sunlight coming from behind:
Pyra, Pandora and my Phone (Blackberry Priv): I see absolutely nothing.
At full brightness even comparing the glossy Pyra screen with the good old mate Pandora screen the Pyra got slightly better results.
Especially with White background/black letters (I use it the other way round normally).
The Pyra screen can be both, a lot brighter and darker than the Pandora screen.
I appreciate later as well, as it is a lot more eye friendly in dark environments.
dTal
Member
- Joined
- May 1, 2016
- Messages
- 34
Somewhat counterintuitively, glossy screens are actually better for direct sunlight - because they preserve incident angles and the sun subtends a small angle, you get a single viewing angle with tons of glare, which can be avoided by moving slightly. On a matte screen, all that light is spread across all viewing angles and cannot be avoided - no "glare", but worse signal-noise ratio.
hns
Well-Known Member
1. exactly. It is easier to modify an SD card than eMMC (which requires a fully working system).
2. yes, eMMC boot works. Sometimes I get reminded when I can boot despite forgetting to insert the new SD card.
pmprog
DNF (Did Not Finish)
- Joined
- Apr 25, 2011
- Messages
- 4,150
Excellent. I too find that in the dark, the screen is still too bright before it goes off.
rygD
Nihilistic Mystic
sebt3
homebrew player (P. & C.)
Ok I promised to give more in depth overview of the device, so here is a little story of my time with a Pyra prototype.
TL;DR : The pyra is an awesome device. The pyra community is as awesome as the device. Following closely the pyra developpement is an enlightening experience !
Initially what ED expected me to work on was 2 things :
1) a deamon that read the volum-wheel value and set the audio volum accordingly.
2) improve the input system
When I got the device, I immediately looked into 1st task. and quickly discovered I'm having and hardware issue with that volum wheel. What a huge bummer !
Actually the deamon kind of exist already : https://dev.pyra-handheld.com/packages/pyra-scripts/blob/master/scripts/letux/volumed
But as you can see in it's code, it's far from optimal. The fact that this is a shell script is not the worst part : it wake up every 0.1s to check for volum wheel value changes. That's very bad for battery life. Luckyly there's a way to do it better : IIO device support for trigger, so the deamon could only wke up if the wheel is moved. see : https://wiki.analog.com/software/linux/docs/iio/iio#trigger_and_software_ring_buffer_support
Even if I cant read the value of my wheel (because of an hardware failure, remember I'm having an old prototype board) I'll try to test the IIO triggers and build the deamon anyway. But since there's a high chance of failure, this have slipped on the bellow of my todo list.
So, I moved to next task. The keyboard definition was (like on the pandora) an Xmodmap file that needed to be loaded somehow. A bit hackish. For some reason I changed my DM to slim, and then the Xmodmap wasn't loaded. So I converted that map to a complete keyboard definition (https://dev.pyra-handheld.com/packages/pyra-config/commit/d36b631ac298823e0d60390d734ddc7e6084e655). One less hack to go
Then for the follow up of this task I needed to disable the mouse on nubs feature, and quickly discovered how badly calibrated was the touchscreen. One IRC discussion later, ED confirmed me that this was an issue we had to look into, so I was starting to work on a calibrator for the touchscreen. Why yet an other calibration tools, you're going to ask. Easy enough, Debian by default use libinput for all input device. It's a good move so Xorg and wayland use the same input system. The problem is : xinput_calibrator doesn't support libinput. Its configuration system is rather smart : it use a transformation matrix that should transform touch coordinates to screen coordinates.
After some times fighting myself with maths, I finally build some formulae and sent my code to Atc so he could test and eventually package it. Result of aTc tests : not working properly on his unit... While discussing about this with aTc, I whined about the screen that bend in the corners. That doesnt help calibrating properly. ED stepped in to say that none of the dev prototypes have the pading required behind the screen to stop that bending.
Having seen some videos of the pyra assembly, I though I may be able to add the padding myself. I have to say, I'm realy shitty when it come to hardware. The only time I opened my Wii, I bricked it, so opening the pandora was clearly not an option. But I tried anyway with the pyra. 3 screws to remove. folded 4 pieces of papers the height I needed and closed the top part back. turning on the pyra crossing finger... and the screen was flickering. I was all omg ! Reopened the top part, to discover that the screen link was badly in place. Put everything correctly in place, closed the top part. and booting it back : fully working and no more bending !
If I can do it, youll be able to do it too. The pyra is realy user servicable !
But code wise it was still a mess. So I started to look around for better maths and quickly I dicovered that someone wrote an other calibration tools for libinput touchscreen (https://github.com/reinderien/xcal/). After a rather long chat with its author (yeah, open-source community is that awesome), we agreed that there was something wrong on the pyra touchscreen drivers. So I was back on IRC with that information. I've been given complete instructions to rebuild the pyra kernel and that specific part (the dtbs). Beside we discussed what might be the culprit in the driver configuration. Before I finally managed to build this correctly, aTc had beaten me to it, he build better drivers configuration that he provided me. With these configurations, and the paddings in place I was now able to correctly work on a better version of xinput_calibrator. After googling some more, I found this : https://math.stackexchange.com/ques...atrix-from-4-projected-points-with-javascript. And tried to implement it. But the math wasnt working : the produced matrix still need to be "Dehomogenizated" which I've failed at doing. So I'm currently working to use the same algorithm as xcal.
While I've shared some link in here, I'm sparing you some of the most complex maths stuff I readed to understand what was going on. If someone is a bit currious, I would suggest you to read what TI provide as documentation of the touchscreen to build this matrix. Full of math !
What a ride so far. I've learned many things already and that's only the begining. All the dev team have been very helpfull so far and very supportive of my attempts to help.
Beside, since, I'm now syndicated the all the dev channels, I'm more in touch with all the dev ongoing, and it's an awesome experience. I've readed some chats way over my head on many things already. And seing how all the issues (like that 4GB memory issue) is being worked on (aka as a great team work) is an heart warming experience.
I've so much more projects in mind to help the pyra on many sides. So keeps tuned.
TL;DR : The pyra is an awesome device. The pyra community is as awesome as the device. Following closely the pyra developpement is an enlightening experience !
Initially what ED expected me to work on was 2 things :
1) a deamon that read the volum-wheel value and set the audio volum accordingly.
2) improve the input system
When I got the device, I immediately looked into 1st task. and quickly discovered I'm having and hardware issue with that volum wheel. What a huge bummer !
Actually the deamon kind of exist already : https://dev.pyra-handheld.com/packages/pyra-scripts/blob/master/scripts/letux/volumed
But as you can see in it's code, it's far from optimal. The fact that this is a shell script is not the worst part : it wake up every 0.1s to check for volum wheel value changes. That's very bad for battery life. Luckyly there's a way to do it better : IIO device support for trigger, so the deamon could only wke up if the wheel is moved. see : https://wiki.analog.com/software/linux/docs/iio/iio#trigger_and_software_ring_buffer_support
Even if I cant read the value of my wheel (because of an hardware failure, remember I'm having an old prototype board) I'll try to test the IIO triggers and build the deamon anyway. But since there's a high chance of failure, this have slipped on the bellow of my todo list.
So, I moved to next task. The keyboard definition was (like on the pandora) an Xmodmap file that needed to be loaded somehow. A bit hackish. For some reason I changed my DM to slim, and then the Xmodmap wasn't loaded. So I converted that map to a complete keyboard definition (https://dev.pyra-handheld.com/packages/pyra-config/commit/d36b631ac298823e0d60390d734ddc7e6084e655). One less hack to go
Then for the follow up of this task I needed to disable the mouse on nubs feature, and quickly discovered how badly calibrated was the touchscreen. One IRC discussion later, ED confirmed me that this was an issue we had to look into, so I was starting to work on a calibrator for the touchscreen. Why yet an other calibration tools, you're going to ask. Easy enough, Debian by default use libinput for all input device. It's a good move so Xorg and wayland use the same input system. The problem is : xinput_calibrator doesn't support libinput. Its configuration system is rather smart : it use a transformation matrix that should transform touch coordinates to screen coordinates.
After some times fighting myself with maths, I finally build some formulae and sent my code to Atc so he could test and eventually package it. Result of aTc tests : not working properly on his unit... While discussing about this with aTc, I whined about the screen that bend in the corners. That doesnt help calibrating properly. ED stepped in to say that none of the dev prototypes have the pading required behind the screen to stop that bending.
Having seen some videos of the pyra assembly, I though I may be able to add the padding myself. I have to say, I'm realy shitty when it come to hardware. The only time I opened my Wii, I bricked it, so opening the pandora was clearly not an option. But I tried anyway with the pyra. 3 screws to remove. folded 4 pieces of papers the height I needed and closed the top part back. turning on the pyra crossing finger... and the screen was flickering. I was all omg ! Reopened the top part, to discover that the screen link was badly in place. Put everything correctly in place, closed the top part. and booting it back : fully working and no more bending !
If I can do it, youll be able to do it too. The pyra is realy user servicable !
But code wise it was still a mess. So I started to look around for better maths and quickly I dicovered that someone wrote an other calibration tools for libinput touchscreen (https://github.com/reinderien/xcal/). After a rather long chat with its author (yeah, open-source community is that awesome), we agreed that there was something wrong on the pyra touchscreen drivers. So I was back on IRC with that information. I've been given complete instructions to rebuild the pyra kernel and that specific part (the dtbs). Beside we discussed what might be the culprit in the driver configuration. Before I finally managed to build this correctly, aTc had beaten me to it, he build better drivers configuration that he provided me. With these configurations, and the paddings in place I was now able to correctly work on a better version of xinput_calibrator. After googling some more, I found this : https://math.stackexchange.com/ques...atrix-from-4-projected-points-with-javascript. And tried to implement it. But the math wasnt working : the produced matrix still need to be "Dehomogenizated" which I've failed at doing. So I'm currently working to use the same algorithm as xcal.
While I've shared some link in here, I'm sparing you some of the most complex maths stuff I readed to understand what was going on. If someone is a bit currious, I would suggest you to read what TI provide as documentation of the touchscreen to build this matrix. Full of math !
What a ride so far. I've learned many things already and that's only the begining. All the dev team have been very helpfull so far and very supportive of my attempts to help.
Beside, since, I'm now syndicated the all the dev channels, I'm more in touch with all the dev ongoing, and it's an awesome experience. I've readed some chats way over my head on many things already. And seing how all the issues (like that 4GB memory issue) is being worked on (aka as a great team work) is an heart warming experience.
I've so much more projects in mind to help the pyra on many sides. So keeps tuned.
Last edited:
Bosbeetle
Terminally lost
Hehe reading that stackexchange reminds me of when I had to rotate some stuff over certain calculated euler-axis and angles. Quite some matrix math but rewarding once you get it. (although I wonder if I still get it when I revisit it)
Pyramancer
Fairly Idle Member
- Joined
- Feb 4, 2017
- Messages
- 232
- Age
- 124
Thanks for the report @sebt3. It's always interesting to get news of the work behind the scenes that's bringing the Pyra closer to fruition.
Noting that you've been working on the keyboard mappings, I was wondering if you could answer some of the questions I have about that.
Some of these questions I asked in a thread in the "Ask Evil Dragon Questions" forum
and
but I don't think anyone reads that, so I didn't get satisfactory answers there!
1) How do the keyboard mappings work when X is not running? Does the Pyra use udev? In particular, if I'm working in a Linux console / Linux virtual terminal on a Pyra, where will the key mappings be configured?
2) Are the function-shifted keys mapped to specific scancodes by the Pyra hardware, or are they sent to the OS untranslated along with the (meta?) modifier? In the thread above, the responses suggested they are not mapped in hardware and, furthermore, that they are only mapped by xmodmap. If these responses are correct, how is a Pyra user to use a Linux console / Linux virtual terminal? For example, if they want to type a semicolon how will they do so? They'll type Fn-, and nothing will happen, or they'll get a comma entered instead of the semicolon they wanted.
Noting that you've been working on the keyboard mappings, I was wondering if you could answer some of the questions I have about that.
Some of these questions I asked in a thread in the "Ask Evil Dragon Questions" forum
and
but I don't think anyone reads that, so I didn't get satisfactory answers there!
1) How do the keyboard mappings work when X is not running? Does the Pyra use udev? In particular, if I'm working in a Linux console / Linux virtual terminal on a Pyra, where will the key mappings be configured?
2) Are the function-shifted keys mapped to specific scancodes by the Pyra hardware, or are they sent to the OS untranslated along with the (meta?) modifier? In the thread above, the responses suggested they are not mapped in hardware and, furthermore, that they are only mapped by xmodmap. If these responses are correct, how is a Pyra user to use a Linux console / Linux virtual terminal? For example, if they want to type a semicolon how will they do so? They'll type Fn-, and nothing will happen, or they'll get a comma entered instead of the semicolon they wanted.
sebt3
homebrew player (P. & C.)
1) For this to happen, one have to have getty process running which is not the case currently I think. But the answer is nope, not yet
2) all you said here is correct.
For both points, that my next project... once I finish with all these math headeaches
sebt3
homebrew player (P. & C.)
Ok, I've converted the modmap to a xkb keymap configuration. Then I've used ckbcomp to convert this to a console keymaping file (using: ckbcomp -layout pyra -variant pyra>tmpkeys) I can then load this file using loadkeys and everything (but accents and a-like) are working as expected. I just dont know where to put that file on
TeDaDeS
Hardcore Member
Sounds like this stuff might also get some results that could be improvements for the Pandora.
Linux-SWAT
Forum Addict!
- Joined
- Feb 13, 2010
- Messages
- 9,187
man loadkeys
sebt3
homebrew player (P. & C.)
as aTc added askarus script for sceen and keyboard brightness, I toyed a bit with that today. From the bright most to the darker settting (well there's a level bellow : off)
Beside these little shots, I've opened the bottom part of my pyra too as I promised. I took the cpu board off, removed the main board took a pict and put everything into place. easy as cake. and the device is still working. I think there's no way to make all this any easier. great job ED you're building the most user servicable handheld in the world... and by a huge margin !
Beside these little shots, I've opened the bottom part of my pyra too as I promised. I took the cpu board off, removed the main board took a pict and put everything into place. easy as cake. and the device is still working. I think there's no way to make all this any easier. great job ED you're building the most user servicable handheld in the world... and by a huge margin !
