Production Pyra photos/videos/thoughts thread


levi said:
Other than daveshah getting a reportedly production level unit to fettle the software with. And he's currently doing amazing things software-wise. Reportedly, it was just the state of the software that was stopping ED from hitting the 100% full power button, and daveshah mentioned that he's having trouble getting all of the patched lined up together, so it sounds good to me that he's noticed that and actually cares about it, and there's a reasonable chance he'll do what's needed to get them all in a better state going forward.

Edit: Indeed, we're in Daveshah's thread. All that information should be hereabouts if you need it.
Click to expand...

I am very grateful for daves work!

I simply would have preferred to have the Pyra and be able to apply the patches hot off the press.. We all know the software will get better, and many people will dev stuff as well....but they can't without the Pyra
 
Well, i was surprised when the packaging wasn't ready, as I'm pretty sure i remember it all being mentioned ages ago, with Traylor Park's name cropping up. Don't know if he actually took up the work though
 
On the software side, I have no idea what ED will consider ready for release, but this is the software status from my perspective.

  • 3D and X11 is now relatively stable. including with LPAE (4GB RAM). There is slightly more tearing than I would like but this is hard to fully get rid of in X11 (you can do triple buffering, but it is quite a bit of work and could introduce more latency if not done right). Fullscreen stuff will hopefully be tearing-free at least. Wayland is some way off due to driver issues but would give a truly tearing-free desktop. Glamor with the X11 modesetting driver might be an alternative to Wayland but again, definitely not something that is blocking release or should be expected around the time of release.
  • There are some other issues around the OMAP5 X11 driver that need fixing. External displays aren't working at all, nor is screensaver mode. It may be that external display hotplugging isn't supported at the time of release but I hope that the HDMI port will work to some extent. HDMI out probably isn't blocking though, as it works enough (shows text during boot) for test purposes.
  • The USB hub driver fix needs to be double-checked and merged. This fixes a bug where the hub wasn't working at all on newer kernels, and was taking 255 seconds to appear on older kernels (thus the modem and USB host ports were also not available for 255 seconds).
  • The reboot fix needs to be finalised - awaiting implementation guidance from people with more OMAP experience to determine whether the proper fix should be in U-boot or the kernel. This was a bug stopping warm reboots (using a reboot from the OS or pressing the hard reset button) from working, as one of the internal system clocks wasn't being configured properly.
  • Some power management fixes need to be forward-ported to the new kernel and checked (otherwise, charges seem to stop before the battery is actually full, and the capacity reading isn't accurate.)
  • Audio needs a bit more testing with the new kernel. None of the old bugs have been fixed yet (and I wouldn't expect them to be fixed pre-release), as getting the AESS built-in audio DSP working is fairly tricky task. What is still missing and less work is a small daemon to handle the headset detection and auto-switching between speakers and headset.
  • The testing and flashing script needs to be finished off.
 
Djoga'Ro said:
A very familiar number, but how did it get there?
Click to expand...
Some kind of timeout inside the USB driver or hardware, before it tried communicating with the hub again after it lost communication due to the hub being reset by its driver at the wrong moment. Unlike true external USB, a chip to chip standard called HSIC is used between the OMAP5 and the hub, which doesn't have automatic disconnect/connection.
 
daveshah said:
On the software side, I have no idea what ED will consider ready for release, but this is the software status from my perspective.

  • 3D and X11 is now relatively stable. including with LPAE (4GB RAM). There is slightly more tearing than I would like but this is hard to fully get rid of in X11 (you can do triple buffering, but it is quite a bit of work and could introduce more latency if not done right). Fullscreen stuff will hopefully be tearing-free at least. Wayland is some way off due to driver issues but would give a truly tearing-free desktop. Glamor with the X11 modesetting driver might be an alternative to Wayland but again, definitely not something that is blocking release or should be expected around the time of release.
  • There are some other issues around the OMAP5 X11 driver that need fixing. External displays aren't working at all, nor is screensaver mode. It may be that external display hotplugging isn't supported at the time of release but I hope that the HDMI port will work to some extent. HDMI out probably isn't blocking though, as it works enough (shows text during boot) for test purposes.
  • The USB hub driver fix needs to be double-checked and merged. This fixes a bug where the hub wasn't working at all on newer kernels, and was taking 255 seconds to appear on older kernels (thus the modem and USB host ports were also not available for 255 seconds).
  • The reboot fix needs to be finalised - awaiting implementation guidance from people with more OMAP experience to determine whether the proper fix should be in U-boot or the kernel. This was a bug stopping warm reboots (using a reboot from the OS or pressing the hard reset button) from working, as one of the internal system clocks wasn't being configured properly.
  • Some power management fixes need to be forward-ported to the new kernel and checked (otherwise, charges seem to stop before the battery is actually full, and the capacity reading isn't accurate.)
  • Audio needs a bit more testing with the new kernel. None of the old bugs have been fixed yet (and I wouldn't expect them to be fixed pre-release), as getting the AESS built-in audio DSP working is fairly tricky task. What is still missing and less work is a small daemon to handle the headset detection and auto-switching between speakers and headset.
  • The testing and flashing script needs to be finished off.
Click to expand...

Doesn't seem like any huge show stoppers.
 
From my actual usage of the Pyra so far (mostly web browsing and 8/16-bit emus), I think a lot of people will have a better out-of-box experience with the Pyra than the Pandora even today (not demeaning the Pandora in any way, it was developed 12+ years ago on an equally shoestring budget...).

Notable improvements:
  • Enough CPU power, RAM and display resolution for modern desktop apps and websites
  • Nubs that actually work reliably
  • Running a proper desktop OS by default, with enough storage space to apt-get install stuff without feeling guilty
  • Keyboard layout more suited to command-line stuff - actually doing tuning/tweaks on the Pyra itself is quite pleasent
  • Fullscreen stuff integrates properly with X11, rather than having weird fights between fullscreen stuff doing direct framebuffer access and X11 also writing to the framebuffer
  • Speakers are louder and clearer than the Pandora even with the imperfect audio setup and not yet being able to use max volume yet
  • Uses a standard charging connector - even with USB-C almost everyone has plenty of micro USB stuff lying around
  • Ability to plug in full/low speed USB devices without a hub or OTG adapter
 
@daveshah
daveshah said:
3D and X11 is now relatively stable. including with LPAE (4GB RAM). There is slightly more tearing than I would like but this is hard to fully get rid of in X11 (you can do triple buffering, but it is quite a bit of work and could introduce more latency if not done right). [ ... ]
Click to expand...

Don't know if this helps but I used debian + xfce for years. In order to get rid of the bad tearing when watching video using vlc I used the compton compositor which did the job nicely. I did the following:

1. install compton
Code: 
sudo apt install -y compton

2. create a compton config in your home directory ~/.compton.conf with the following content (I did not write this config myself, didn't bother, but it worked quite well for me)
Code: 
backend = "glx";
paint-on-overlay = true;
glx-no-stencil = true;
glx-no-rebind-pixmap = true;
vsync = "opengl-swc";

# These are important. The first one enables the opengl backend. The last one is the vsync method. Depending on the driver you might need to use a different method.
# The other options are smaller performance tweaks that work well in most cases.
# You can find the rest of the options here: https://github.com/chjj/compton/wiki/perf-guide, and here: https://github.com/chjj/compton/wiki/vsync-guide


# Shadow
shadow = true;            # Enabled client-side shadows on windows.
no-dock-shadow = true;        # Avoid drawing shadows on dock/panel windows.
no-dnd-shadow = true;        # Don't draw shadows on DND windows.
clear-shadow = true;        # Zero the part of the shadow's mask behind the window (experimental).
shadow-radius = 7;        # The blur radius for shadows. (default 12)
shadow-offset-x = -7;        # The left offset for shadows. (default -15)
shadow-offset-y = -7;        # The top offset for shadows. (default -15)
shadow-exclude = [
 "! name~=''",
 "n:e:Notification",
 "n:e:Plank",
 "n:e:Docky",
 "g:e:Synapse",
 "g:e:Kupfer",
 "g:e:Conky",
 "n:w:*Firefox*",
 "n:w:*Chrome*",
 "n:w:*Chromium*",
 "class_g ?= 'Notify-osd'",
 "class_g ?= 'Cairo-dock'",
 "class_g ?= 'Xfce4-notifyd'",
 "class_g ?= 'Xfce4-power-manager'"
];

# The shadow exclude options are helpful if you have shadows enabled. Due to the way compton draws its shadows, certain applications will have visual glitches
# (most applications are fine, only apps that do weird things with xshapes or argb are affected).
# This list includes all the affected apps I found in my testing. The "! name~=''" part excludes shadows on any "Unknown" windows, this prevents a visual glitch with the XFWM alt tab switcher.

# Fading
fading = true; # Fade windows during opacity changes.
fade-delta = 4; # The time between steps in a fade in milliseconds. (default 10).
fade-in-step = 0.03; # Opacity change between steps while fading in. (default 0.028).
fade-out-step = 0.03; # Opacity change between steps while fading out. (default 0.03).
#no-fading-openclose = true; # Fade windows in/out when opening/closing

detect-client-opacity = true; # This prevents opacity being ignored for some apps. For example without this enabled my xfce4-notifyd is 100% opacity no matter what.

# Window type settings
wintypes:
{
  tooltip = { fade = true; shadow = false; };
};

3. make compton start at boot time through the ui
XFCE settings manager -> settings manager -> session and startup -> application autostart -> add -> Command: compton -b
 
daveshah said:
On the software side, I have no idea what ED will consider ready for release, but this is the software status from my perspective.

  • 3D and X11 is now relatively stable. including with LPAE (4GB RAM). There is slightly more tearing than I would like but this is hard to fully get rid of in X11 (you can do triple buffering, but it is quite a bit of work and could introduce more latency if not done right). Fullscreen stuff will hopefully be tearing-free at least. Wayland is some way off due to driver issues but would give a truly tearing-free desktop. Glamor with the X11 modesetting driver might be an alternative to Wayland but again, definitely not something that is blocking release or should be expected around the time of release.
  • There are some other issues around the OMAP5 X11 driver that need fixing. External displays aren't working at all, nor is screensaver mode. It may be that external display hotplugging isn't supported at the time of release but I hope that the HDMI port will work to some extent. HDMI out probably isn't blocking though, as it works enough (shows text during boot) for test purposes.
  • The USB hub driver fix needs to be double-checked and merged. This fixes a bug where the hub wasn't working at all on newer kernels, and was taking 255 seconds to appear on older kernels (thus the modem and USB host ports were also not available for 255 seconds).
  • The reboot fix needs to be finalised - awaiting implementation guidance from people with more OMAP experience to determine whether the proper fix should be in U-boot or the kernel. This was a bug stopping warm reboots (using a reboot from the OS or pressing the hard reset button) from working, as one of the internal system clocks wasn't being configured properly.
  • Some power management fixes need to be forward-ported to the new kernel and checked (otherwise, charges seem to stop before the battery is actually full, and the capacity reading isn't accurate.)
  • Audio needs a bit more testing with the new kernel. None of the old bugs have been fixed yet (and I wouldn't expect them to be fixed pre-release), as getting the AESS built-in audio DSP working is fairly tricky task. What is still missing and less work is a small daemon to handle the headset detection and auto-switching between speakers and headset.
  • The testing and flashing script needs to be finished off.
Click to expand...

i think ED should not hold back because of software..hardware is ok only when everything is really done, while software is ready good to go when you can do something and do updates...
 
@ghostpatch

Thanks, very good to know that tearing-free X11 is actually possible :) Unfortunately as we only have GLES and not full GL getting these fancy compositors working might be a bit tricky (might be doable with gl4es but I don't know what performance is like). If anyone knows a decent compositor with GLES2 support, that would certainly be interesting to try.
 
Compositors in general tend to cause tearing on video playback, though, because they break video Vsync. Some of them pay more attention on this issue and try to keep it at a minimum, but they can't prevent it from happening.

daveshah said:
If anyone knows a decent compositor with GLES2 support, that would certainly be interesting to try.
Click to expand...
Compiz and KWin already introduced GLES2 support about 8 years ago.
 
As far as I know marco itself isn't using DRI3, but merely designed to work well (in theory at least) with applications using DRI3 which is fortunate as that is what we are using for 3D+X11. It is interesting that it is supposed to be tearing-free, as in practice in the current state it is not tearing-free at the left edge of the screen (i.e. for the first 10-20% of lines in scanout order).

Either the omap5 X11 driver's present support is just broken (entirely possible) or it relies on the X11 driver also using double/triple buffering. It may also rely on an X11 driver that is able to flip the scanout buffer, but it makes the assumption that an arbitrary pixmap is scanout-capable which won't be true in our case, because scanout buffers have to be TILER-compatible which would add unnecessary overhead in other cases.
 
You must log in or register to reply here.

Similar threads

Wally
Pyra first Run Wizard
Replies
12
Views
4K
Christoph.Krn
Christoph.Krn
EvilDragon
Pyra Prototype Videos - Askarus Edition
2 3 4
Replies
63
Views
23K
MrLimatex
MrLimatex
L
Creating an "empty" OS for the pyra
2
Replies
24
Views
8K
levi
levi
Orz
My Thoughts on the Pyra
3 4 5
Replies
91
Views
11K
levi
levi
Gren
Early Pyra Impressions
Replies
7
Views
2K
matzesu
matzesu
Back
Top