BBB desktop manager output resolution when disabled?

[Michael Ascenzi]

I'm working with the BBB with the utilization of the DLP2000 EVM cape from TI. I'm having difficulties with the speed at which I can transfer 640x320 images across across to the EVM. 

One thing that has been asked has to do with the desktop manager and the image that rendered from the manager. The default resolution of the BBB is 1920x1080 @24hz. Now obviously we can modify the resolution by using xrandr to switch up the resolution to 640x480 so that it would run at 60hz. 

Part of the software that takes the images and transfer them over the framebuffer to the EVM is a command to shutdown the desktop manager. If I don't shutdown the manager, when I send over a frame, there's a chance that the desktop can insert its own image between the images I'm sending. This is an issue, as I need the images I'm sending and only those images. 

So my question is whats the resolution of the BBB if I disable the desktop manager? is it still 1920x1080? or is that no longer a factor?

I might be completely off base in my understanding this, I'm guessing that I am. If i disable the desktop manager, do I still have control over the screen resolution with xrandr?

[Robert Nelson]

The desktop manager get's the default list of resolutions from the
monitor plugged into the HDMI port.

You can either, not have anything plugged in, and it'll use a small
old framebufffer default, or override the edid values thru a kernel
boot arg listed in /boot/uEnv.txt...

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Michael Ascenzi]

Robert, 

So I'm not actually connecting an HDMI to the BBB. The EVM is a projector cape that we have sitting ontop of the BBB. 

So if nothings plugged in, as you said, it would use a small old framebruffer. So the question is does that old framebruffer have a default resolution with a transfer speed? or can it be adjusted?

Michael

[Robert Nelson]

On Tue, Mar 24, 2020, 9:32 PM Michael Ascenzi <masce...@gmail.com> wrote:

Robert, 

So I'm not actually connecting an HDMI to the BBB. The EVM is a projector cape that we have sitting ontop of the BBB. 

So if nothings plugged in, as you said, it would use a small old framebruffer. So the question is does that old framebruffer have a default resolution with a transfer speed? or can it be adjusted?

I thought that was the case, but was confused when you stated.

1920x1080 @24hz

Which isn't the true case, it's running the resolution of the projector..

Regards,

[Michael Ascenzi]

so looking at the BBB documentation

so these are just the supported resolutions for the BBB correct?

In my case, the EVM would have its default resolution associated with it, which is what the BBB would be set to. Correct? 

Would changing the resolution via Xrandr have any affect on the image transfer rate from the BBB to the EVM? I don't have access to the BBB & EVM at the moment. At the office. or else I would try it. I'll try to head  into the office tomorrow. 

Speaking with the guys over at TI, the EVM is set to a default rate of 60hz based on the data being piped over the parallel video input. They say that the EVM will update at 60hz, but the week link is the speed at which the BBB can load and push the image files over the parrallel video input. 

right now we have an oscilloscope connected to the vsync pin of the gpio on the BBB. Which is part of the parrellel video input.  We assumed that the BBB was working at 24hz cause of what we were seeing on the scope. This is our suspicion because when we measured VSYNC directly on the beagle using the P8 expansion header (pin 27 lcd_vsync) and an oscilloscope we measured 23.6 Hz (basically round up and its 24 Hz). 

Any thoughts?

Michael

[Robert Nelson]

On Tue, Mar 24, 2020 at 10:01 PM Michael Ascenzi <masce...@gmail.com> wrote:

so looking at the BBB documentation

so these are just the supported resolutions for the BBB correct?

You added the word "just".. That's untrue... In the documentation that is a list of "standard" supported monitor resolutions.

 

In my case, the EVM would have its default resolution associated with it, which is what the BBB would be set to. Correct? 

The DLP2000, is 640x360 as specified in the display-timings configuration:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/DLPDLCR2000-00A0.dts#L228-L242

 

Would changing the resolution via Xrandr have any affect on the image transfer rate from the BBB to the EVM? I don't have access to the BBB & EVM at the moment. At the office. or else I would try it. I'll try to head  into the office tomorrow. 

No, it has a fixed resolution.

 

Speaking with the guys over at TI, the EVM is set to a default rate of 60hz based on the data being piped over the parallel video input. They say that the EVM will update at 60hz, but the week link is the speed at which the BBB can load and push the image files over the parrallel video input. 

right now we have an oscilloscope connected to the vsync pin of the gpio on the BBB. Which is part of the parrellel video input.  We assumed that the BBB was working at 24hz cause of what we were seeing on the scope. This is our suspicion because when we measured VSYNC directly on the beagle using the P8 expansion header (pin 27 lcd_vsync) and an oscilloscope we measured 23.6 Hz (basically round up and its 24 Hz). 

Any thoughts?

Regards,

[Michael Ascenzi]

well as you stated, so it is. I just got home from the office picking up the BBB and EVM board. Ran Xrandr and it spit out the resolution of 640x360. so as you state, not doubting you just confirming, you were correct that the beaglebone would be set to the 640x360 resolution.

I'm seeing a couple things that isn't clear to me. The first is when ever I run xrandr the very first line is

         xrandr: Failed to get size of gamma for output default

I've done some searching and I haven't found a clear resolution or what this even means. I've even attempted to set the gamma with no success. 

Next is the fact that the framerate is missing next to the systems available active resolution. I see

        640x360      0.00*

I followed instructions on generating a new system resolution. I started off with generating a new Modeline

      > cvt 640 360 60 

next I added the new modeline to create a new resolution

      > xrandr --newmode "newly generated mode"

When I do this I get back 

      > xrandr: Failed to get size of gamma for output default

the instructions I have now have me adding the new mode to the list of resolutions available. 

      > xrandr --addmode default 640x360_60.00

and again I get the failed ...gamma ... default message.

now if I check xrandr it shows a new available option with a refresh of 60 (59.84)

      > xrandr

however when I go to select this new option it doesn't switch it remains on the original/default value. 

So i've tried this as well. I'm assuming, and please correct me if I'm wrong, but it doesnt matter what the number is next to the resolution. Its still limited by what the BBB can push out over the parallel bus? if the vsync is fixed at 23.6hz on the BBB and the DLP2000 is capable of 60hz, is there a way to control the vsync or I guess more specificly, the peripheral clock. Can I adjust this to increase the transfer rate from the BBB to the EVM?

Michael

P.S. Thank you so much for your insight. I do appreciate it. 

[Robert Nelson]

I don't have any equipment to refute your "23.6hz" claim, but the
clock-frequency is set in the overlay:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/DLPDLCR2000-00A0.dts#L231

clock-frequency = <5900000>;

So if TI says it's "60hz" it's "60hz"...

xrandr isn't going to give you anything useful, as that reads the edid
register of the attached device (aka monitor plugged in).. In this
case we have a display panel driver, attached to the tilcd driver.

[Michael Ascenzi]

Robert, 

I was hoping that you could clarify something for me. When you reference clock-frequency = <5900000> are you referring to the PCLK frequency associated with the LCD Controller on the SITARA processor? 

Based on the requirments of the DVD EVM we need a PCLK of 16700000. Is there a way for us to make changes that would give us this abilility?

Michael

[Robert Nelson]

On Thu, Mar 26, 2020 at 10:48 AM Michael Ascenzi <masce...@gmail.com> wrote:
>
> Robert,
>
> I was hoping that you could clarify something for me. When you reference clock-frequency = <5900000> are you referring to the PCLK frequency associated with the LCD Controller on the SITARA processor?

I was only referencing the value defined in the overlay.

You can also look at the device tree documentation, that's specif node
is defined here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/panel/display-timing.txt

- clock-frequency: display clock in Hz

> Based on the requirments of the DVD EVM we need a PCLK of 16700000. Is there a way for us to make changes that would give us this abilility?

I have no idea..

When TI originally submitted that Overlay:

https://github.com/beagleboard/bb.org-overlays/commit/fa41a83b8fd1333cac1791fb62a86bc8ef141dea#diff-3e2cb7c335a233d032cdf72c89b43555

it was set with: clock-frequency = <5900000>;

[Michael]

Hi Robert. 

So we are attempting to make some simple changes to the Device tree overlay for the DLP2000. I have a few questions for you. 

1) I'm attempting to compile the .dts file found in /opt/source/bb.org-overlays/src/arm. Specifically the DLPDLCR2000-00A0.dts file. However, when I give the command

dtc -O dtb -o DLPDLCR2000-00A0.dtbo -b 0 -@DLPDLCR2000-00A0.dts

I end up getting an error. 

PDLCR2000-00A0.dts
Error: DLPDLCR2000-00A0.dts:11.1-9 syntax error
FATAL ERROR: Unable to parse input tree

I can't seem to find a solution for compiling the device tree properly. 

2) There are three locations that I have found for the dtbo file to be placed. 

    /lib/firmware/DLPDLCR2000-00A0.dtbo

    /var/tmp/mkinitramfs_hnr78y/lib/firmware/DLPDLCR2000-00A0.dtbo

    /var/tmp/mkinitramfs_UPVFx2/lib/firmware/DLPDLCR2000-00A0.dtbo

should I back up all three files and then paste the new compiled overlay in all three, or....

3) I decided to take a look at each of the three locations, justs for shits and giggles. It seems the first and 2nd location for the .dtbo files are exactly the same. But the file located at /var/tmp/....UPVFX2/lib/firmware seems to be very different from the first two locations. The first two locations look almost identical to the file located at /opt/source/bb.org-overlays/src/arm/DLPDLCR2000-00A0.dts, but very different from the link you provided me at 

https://github.com/beagleboard/bb.org-overlays/commit/fa41a83b8fd1333cac1791fb62a86bc8ef141dea#diff-3e2cb7c335a233d032cdf72c89b43555

I'm going to throw the same questions up on TI's forum, but I wanted to see if you had any insight as well. 

thank you for your time and help. 

best regards, 

Michael

[Robert Nelson]

On Tue, Mar 31, 2020 at 8:25 AM Michael <masce...@gmail.com> wrote:
>
> Hi Robert.
>
> So we are attempting to make some simple changes to the Device tree overlay for the DLP2000. I have a few questions for you.
>
> 1) I'm attempting to compile the .dts file found in /opt/source/bb.org-overlays/src/arm. Specifically the DLPDLCR2000-00A0.dts file. However, when I give the command

> dtc -O dtb -o DLPDLCR2000-00A0.dtbo -b 0 -...@DLPDLCR2000-00A0.dts

> I end up getting an error.
> PDLCR2000-00A0.dts
> Error: DLPDLCR2000-00A0.dts:11.1-9 syntax error
> FATAL ERROR: Unable to parse input tree
>
> I can't seem to find a solution for compiling the device tree properly.

Well, you forgot to call gcc's pre-processor before you called "dtc",
magic numbers aren't maintainable..

Just call 'make' from the base directory:

debian@bbb-pwr01-ser09:/opt/source/bb.org-overlays$ make
src/arm/DLPDLCR2000-00A0.dtbo
DTC src/arm/DLPDLCR2000-00A0.dtbo

[Robert Nelson]

> 2) There are three locations that I have found for the dtbo file to be placed.
> /lib/firmware/DLPDLCR2000-00A0.dtbo
> /var/tmp/mkinitramfs_hnr78y/lib/firmware/DLPDLCR2000-00A0.dtbo
> /var/tmp/mkinitramfs_UPVFx2/lib/firmware/DLPDLCR2000-00A0.dtbo
> should I back up all three files and then paste the new compiled overlay in all three, or....

The last two of those are tmp locations for when "update-initramfs" ran...

>
> 3) I decided to take a look at each of the three locations, justs for shits and giggles. It seems the first and 2nd location for the .dtbo files are exactly the same. But the file located at /var/tmp/....UPVFX2/lib/firmware seems to be very different from the first two locations. The first two locations look almost identical to the file located at /opt/source/bb.org-overlays/src/arm/DLPDLCR2000-00A0.dts, but very different from the link you provided me at
> https://github.com/beagleboard/bb.org-overlays/commit/fa41a83b8fd1333cac1791fb62a86bc8ef141dea#diff-3e2cb7c335a233d032cdf72c89b43555

Correct, it looks different as that was the version TI sent me, and
since then i've been fixing it for newer kernel versions..

https://github.com/beagleboard/bb.org-overlays/commits/master/src/arm/DLPDLCR2000-00A0.dts

[Michael]

Excellent, this worked perfect. However there is one thing. While it built the new blob, verified by decompiling again. It did not move it to the new directory. I'm assuming I could just place it in the /lib/firmware directory and it should be fine at this point.

Michael