I've updated my software info-beamer in the last month to support the Pi4 and its new abilities. I've been making lots of progress recently and I wanted to show a small demo of one of the nicer and I think unique features at the moment: It is capable of playing H264 (H265 hopefully soonish) videos a...
I'm pretty certain it has been stated that the goal is to have the EEPROM resident firmware/code from an apt package at some point. A reboot will be required to activate it of course.
The means to do it are already there. It just hasn't been turned into a simple to use form. I appreciate your quick response, but I'm not sure how you end up with this conclusion. Although I too seriously doubt that this is all we'll ever get, right now the *only* way to update seems that recovery....
Will or is it possible to do EEPROM bootloader updates "unattended"? So having them done automatically without swapping SD card manually? I imagine a process that skips the update and continues the normal boot process if the provided update is identical to the one active. Or maybe writing a new EEPR...
Likewise you can override the setting using the "Broadcast RGB" property, reported by modetest as: Ah. That it. I'll play around with that eventually as I've also had some color range related complaints in the past. This should help. Thanks! Yes, the refresh rate is rounded. DRM does add the dropfr...
rotating through video_render involves transposing a YUV420 buffer at 1.5 bytes/pixel.
rotating through display_rotate involves transposing an RGBA32 buffer at 4 bytes/pixel. Significantly more work.
The behaviour from a timing perspective is identical, and the kernel DRM API has a magic function called drm_default_rgb_quant_range to deal with the RGB range (it compares the mode against the standard CEA modes, and returns HDMI_QUANTIZATION_RANGE_LIMITED if it matches and isn't VGA). None of thi...
Correct, FKMS is not exposing transpose as it has to be done via a two pass render using the transposer hardware block. It requires an extra buffer for the transposed element, and the transposer is limited to 1080p when transposing. It also falls over when it comes to updating the elements - DRM is...
Hi All I have recently got my new pi4 device. However, I am getting trouble trying to get the device id of my primary monitor. I am using vc_dispmanx_display_open(int device_id) to open a display when i want to draw something to that monitor and I managed to find that the device_id for two display ...
DRM is sitting on top of the firmware modesetting. tvservice is an alternate way into the same subsystem. Using tvservice will cause grief with DRM as DRM has no idea that things have changed (it believes it is master and no one else can change things). Thanks for the clarification. modetest -M vc4...
Continuing the journey speaking to myself: The rotation seems to be indeed limited to a few options. It it looks like it's impossible to rotate a video by 90/270 degree right now. Is that something that will be supported in the future? Or is the `video_render` component the only way to achieve this?
If I set a video mode with `tvservice` on a FullHD display, for example like this: root@raspberrypi:~# tvservice -e "CEA 4" Powering on HDMI with explicit settings (CEA mode 4) root@raspberrypi:~# tvservice -s state 0xa [HDMI CEA (4) RGB lim 16:9], 1280x720 @ 60.00Hz, progressive The modetest tool d...
Anything? Anyone? I was able to figure out how to rotate a DRM plane (although only the rotate-180 bitmask value seem to work) and found the "zpos" property. Looking at the output of modeset (below) and my own output doesn't mark the "zpos" plane property as immutable. I tried setting various values...
Mind giving a few insights on how scheduling works now? Previously with OMX I've used the schedule component together with a clock to sync audio and video. How does a similar pipeline now work with mmal? Are you using the schedule component now?
I'm currently working on a DRM/MMAL based video playback using the new Pi4 APIs. Essentially I'm trying to replicate (as a first step) what omxplayer does with dispmanx and OMX. I'm having a few difficulties understanding how that's all supposed to work. With OMX it was pretty simple: Create a dispm...
Are those freshly created textures on the change? In which case something may well be memsetting it to 0, leaving a transparent alpha channel. I'm not sure I fully understand what you're asking, but right now the code creates a configurable number (I tried from 2 to 10) number of textures with the ...
You should be able to find that out if you run `vcgencmd dispmanx_list`. You'll see the various dispmanx parameters used to compose the final video output.
Can you add frame numbers to the top and bottom half of the images and check to see if the top and bottom halves are from the same image? I can't quite tell from your image, but it looks like the bottom half is from an earlier frame, in which case I have a guess. Unfortunately that doesn't seem to ...
They all load libEGL_mesa.so but I didn't see any of the combinations load libGL_mesa.so lib at least on my pi4.
Right. You're correct. I meant libEGL_mesa.so, not libGL_mesa.so. I've fixed my previous post. I've yet to understand how all those GL lib play together on the Pi4.
MMAL does allow ARM side components, and indeed there is a libavcodec wrapper component. It hasn't been used for a long time, but it may be possible to resurrect it to allow use of H265 from MMAL. No such option really exists in IL, therefore this is not an option with that API. Isn't the ALSA supp...
I'm using GL without X and use DRM directly. I also ran into this issue. I'm linking with -lGLESv2 -lEGL. Regardless of that, the call to eglGetPlatformDisplay seems to dynamically load libEGL_mesa.so.0 (after consulting /usr/share/glvnd/egl_vendor.d/50_mesa.json). So even without explicitly linking...
I've noticed that the colors of the image seem weird is that what the image should look like? which drm fourcc are you using for your egl import? Is the incoming image RGB or YUV? DRM fourcc should be XB24. The isp component converts to RGBA and the colors are correct (it's 1:14 into this video ). ...