Raspberry PI CRTSwitchRes no x11 overheads

General Development
#1

Hey guys,

So I have started from the ground up on the resolution switching. There is now no need for x11, this removes the overheads. Currently it’s in early stages.

This will be compatable with all distros, including Lakka. I am sending data directly to the firmware (VCHIQ).

Here is a short teaser of it running, the resolution for the menu switches to 1920x240@60.

@hunterk I am using an old biuld for testing. It seems that the menu options for CRTSwitchRes have been removed for arm in the latest build (1.7.5). Can you confirm this.

1 Like
#2

Hey, no, not that I know of. I think they’re considered an “advanced option” now, so you’ll need to go to settings > user interface > show advanced options ON, and the options themselves might have been moved since you last used it, but they should definitely still be there somewhere, since a lot of people are using it.

#3

I can confirm that windows and Linux still have the options in th latest nighyly. Android has the options in the latest release. But RPi latest nightly does not even with advanced options on. @hunterk

#4

Is this outputting through the HDMI ? so stuff like HDMI to vga/scart should work… or for us in the USA maybe a HDMI to vga component transcoder …

VGA https://www.ebay.com/i/192116647418?chn=ps

SCART

#5

how are you getting it on RPi? Lakka? RetroPie? Something else?

#6

Im using raspbian as always. Compiling from source

Using: --disable-x11 --enable-neon --enable-floathard --enable-udev

So, I don’t see why the options would be gone!

#7

It is manipulating the HDMI frame buffer so it will work for HDMI to vgaand others.

#8

Ah, it might be the --disable-x11 that’s doing it. I think they might be ifdefed to require it, since they previously required xrandr. Can you try compiling without that switch?

#9

Latest update, full dynamic switching for raspberry Pi

1 Like
#10

dang, that’s awesome. Looks super-fast, too!

1 Like
#11

does it work in linuxmint without x11？

#12

amazing! i know retropie will be super hyped to use this. well done! was this using the vcgen api?

1 Like
#13

Yes it is using the vcgen API.

#14

OK so I tried compiling without the --disable-x11 I have also compiled with --enable-x11. However, the CRT options are not visible in the menu. It seems they have been hidden for Arm or Arm-neon. Can you check this out? It would be nice to have these option back in for Raspberry Pi

#15

No but I have a whole new switching method coming for x1. It’s more stable and does not use the external xrandr.

#16

Ok so I have implemented native refresh rates for the Raspberry PI. No VSYNC or audio sync being used with no stutter or tearing.

@hunterk any info on the missing CRT options for Raspberry PI on 1.7.5?

#17

which one should I choose,x1 or wayland？I look forward to using ra in kms under no x server

#18

Twinaphex found what was hiding the options:

line 6649 of menu_displaylist.c is the current conditional

if (!string_is_equal(video_display_server_get_ident(), "null"))

The assumption was that we would hide the options if there was no X or WDM, but since this works without either, we’ll have to rethink that, or just ditch it altogether.

I couldn’t really find anything online that would let us test for RPi, specifically, so we might just have to lose it altogether.

#19

Oh that makes sense.

Could a new video display server be implemented for fbturbo? As this is what the PI uses

That could be a way round it. Plus this should be where the PI switch code should go.

#20

Yeah, that’s certainly doable (not by me; it’s out of my league, but you know…) and it’s actually what Twinaphex suggested, as well.