Different screen resolution after Resin OS upgrading


#1

Hi everybody,

I’m running Resin on a RaspberryPi3, the application runs with SailsJs as a backend and Electron + AngularJs as frontend.
The application was developed for Resin OS 1.2.6 and right now we’re trying to migrating it to the latest version possible (2.7.5).

Everything went smoothly, apart from the change of screen resolution. The screen attached to the raspberry is this one. Since its resolution is 1024x600 and it’s not one of the canon supported by the hdmi_mode variable with hmdi_group=2, it was set a custom value.

The following is the config.txt file content (omitting the commented parts):

enable_uart=1
dtparam=i2c_arm=on
dtparam=spi=on
disable_splash=1
dtparam=audio=on
core_freq=250
disable_overscan=1
dtoverlay=i2c-rtc,ds1307
fixup_file=fixup_x.dat
force_turbo=1
framebuffer_depth=24
hdmi_cvt=1024 600 60 6 0 0 0
hdmi_group=2
hdmi_ignore_edid=0xa5000080
hdmi_mode=87
max_usb_current=1
overscan_bottom=0
overscan_left=0
overscan_right=0
overscan_top=0
safe_mode_gpio=4
start_file=start_x.elf

This configuration running on resin OS 1.2.6 fits perfectly the screen, while after the migration the application slightly trespasses the screen borders in all the directions.
I tried everything, from changing the fleet configuration variables from the dashboard from entering directly inside the device in both production and development mode (in the latter i tried to modify the configuration file by hand) but still nothing happened.

I talked with the online support and they kindly helped me to solve this problem but still my screen resolution doesn’t fit the screen dimensions properly. I’m writing this post hoping that someone had the same problem in the past and could eventually help me to solve it.

Thank you in advance for any kind of help!


#6

@pBassi, have you tried running the tvservice command to set the correct group and mode in config.txt? Here is an article that may help: http://www.opentechguides.com/how-to/article/raspberry-pi/28/raspi-display-setting.html

Please let us know if that does not help.


#8

I already followed the instruction provided by your link.
It’s not an overscan problem since the disable_overscan variable is set to 1.

Regarding the edid.dat file, I’m able to generate it but it seems that there is no edidparser on the Raspberry and so I’m not able to parse and save it inside the edid.txt file. That’s the main reason why I disabled the parsing of the edid file with the proper code in the variables.


#9

@pBassi have you also tried having overscan enabled with positive overscan values?


#10

I tried with the overscan enabled and I can adapt some of the dimensions to the screen, but only the top and the bottom one. The horizontal values are still stretched and out of sight: I forced the resolution to a value that is not common for the screen (1060) and actually I’m able to fit it in the space, but I don’t know if this is the right way to proceed (I mean, the screen is shipped with a fixed resolution, width and height, so I find strange that you have to make this workarounds in order to adapt the video output only because I changed the Resin OS version).


#14

Hi, have you tried using a different aspect ratio? Like:

hdmi_cvt=1024 600 60 3 0 0 0


#15

Also, what were the overscan options you tried? You did leave

disable_overscan=1

and then added positive values to the overscan_ params, right?

If not, can you do that and try with different values to overscan_ params (try even with big values so to be sure you notice the change)


#18

I tried different aspect ratio but it didn’t work in any of the 6 cases.
I added different values to the overscan’s four parameters and I can notice the difference (the screen is actually reduced in dimension), but as I already said before, it’s not a problem of having borders around the screen, it’s actually a problem of fitting the image in the given space of the screen resolution.
As a further example, I tried the 1280x768 resolution (bigger than the 1024x600 of the screen) and it actually adapts the content, but obviously it has black borders all around that are not removable.
It seems like that the overscan actually fixed the problem, but not in the way that it should (theoretically it shouldn’t have changed anything in the upgrade of the OS).


#21

Can you please paste the config with the values that you have tried? I was informed that the firmware has been upgraded in the meanwhile so probably it’s related to the BSP update for the pi.

Thanks,
ilias


#22

It’s in the first post


#34

Hi,
you said:

I tried with the overscan enabled and I can adapt some of the dimensions to the screen

Can you try like suggested above?

Also, what were the overscan_ values you tried? You did leave
disable_overscan=1
and then added positive values to the overscan_ params, right?
If not, can you do that and try with different values to overscan_ params (try even with big values so to be sure you notice the change)


#35

I tried with

disable_overscan=1

and different parameters, big, small, positive and negative.
The borders move and it’s ok, but the problem is another one. The application doesn’t fit the amount of space given, and applying an overscan bias cuts out that amount of space.
Is there a possibility that the application itself can interfere with the resolution of the screen? Nothing has been touched during the migration and there is no code at all that forces a particular kind of resolution.
Can it be a faulty iteration with Electron?


#36

Can you try another GUI app on your device? Maybe give this sample project a try and check the behavior? https://github.com/resin-io/resin-electronjs.git


#37

Sorry guys for the delay.
It seems like I solved the problem in this way: I set the screen resolution in the fleet configurations the way i need, then i found out that electronjs took some parameter to tweak the screen resolution by itself, setting it to the screen’s original one.
This mode did the trick, I don’t know if it is a universal solution but I want to let you know that it worked.

Thanks for all the support, have a nice day!


#38

Good to hear it got resolved. So the fix was setting electronjs’ resolution to the original screen resolution?


#40

Exactly, together with setting the fleet configuration’s resolution to the new one that helps the screen to fit the stretch.
Thanks for all your help!