@outdoorbits
Did you add the setup requirement for the build?
Because looking at the details, it's mainly No module named 'gpiozero' #271
I added it in #277, I could PR it to your fork instead of main if that's fine?

You are welcome. I installed gpiozero by apt as mentioned at https://gpiozero.readthedocs.io/en/latest/installing.html

@outdoorbits Yeah I understand that, but when the tests run, I suspect that the setup needs to be made aware of the necessary packages for it to function correctly. I opened a PR for your fork

@rm-hull ...

Looks like some test failures need investigating

I recently opened issue #283. However, this was quite pointlessly marked as a duplicate with #270 and was even renamed similarly.
However, the point of my post was completely different.
The sense was rather similar to this PR.
I apologize for the abuse of this PR, but I hope you understand, it is very related.

1. In #283, I proposed a solution to the RPi.GPIO dependency and not the option to make this dependency optional.
   I personally find it pointless to introduce (in a relatively complicated way) a dependency on gpiozero instead of depending on RPi.GPIO when the rpi-gpio library exists.
   With the rpi-gpio library, luma.core should work without change (!) for both RPi4 and RPi5. Only perhaps the [options] section in the config.cfg file should be changed (instead of RPi.GPIO it should be rpi-gpio). However, I consider this to be only a temporary solution.
2. The requirement that the dependency (either on RPi.GPIO or on gpiozero or on rpi-gpio) be optional is completely legitimate, it makes sense especially for displays with an SPI interface. However, I didn't really want to address this issue in #283, and I don't intend to address it here either.
3. Both libraries (both gpiozero and rpi-gpio) depend on lgpio and do the same thing - convert all gpio requests to lgpio calls. So it's clear from this that using gpiozero and likewise rpi-gpio doesn't really make sense - it's an unnecessary intermediate step. I propose to skip this intermediate step and instead of depending on RPi.GPIO make a direct dependency on lgpio.

I tried to make the necessary modifications and I already have a working version!
I'm using lgpio calls directly and not using either gpiozero or rpi-gpio. But I only tested it for RPi4, because I don't own RPi5.
It's also probably not a complete solution - for example, I don't use cmdline.py at all, and it would probably require a lot more comprehensive testing.
I even have two versions of the solution. Version "2" uses spidev in the same way as before, while version "3" uses SPI, implemented in lgpio.
I did some simple speed measurements. If I mark the version using rpi-gpio (which is actually the unchanged official version of luma.core) as version number "1", the results were as follows:
Version "1" was the slowest and version "3" was the fastest. But I do not rule out that my measurement method does not have a hidden mistake.

But I don't know if anyone is interested in my solution. I don't intend to do a PR (as was the case with adding the sh1107 display to the luma.oled library, maybe thijstriemstra will remember). If you are interested, let me know how to get it to you.

@Pako2 Hey there, yeah I'm definitely interested in anything that works with a RPi5.

@RampantDespair OK, so here it is.
The attached zip contains five files.
The serial2.py and serial3.py files are alternate versions of the original serial.py file. They need to be placed in the .../luma/core/interface directory.
The files test1.py, test2.py and test3.py are the files I used to perform the testing.
test1.py uses the original version of serial.py and therefore needs to have the rpi-gpio library installed.
test2.py uses a modified serial2.py file. This means it needs the lgpio and spidev libraries.
test3.py uses a modified serial3.py file. It only needs the lgpio library.

I am aware that my solution probably contains some bugs as the testing was only very superficial.
Example of possible errors:

1. I don't understand at all what the FTDI related stuff is for in the luma.core library. So I can't even test it.
2. I don't use the command line to call luma, so there will probably be some problems there as well

It should also be noted that my "3" version has a limitation compared to the original version - it does not allow using non-HW pins as CE. This is given by the lgpio implementation of SPI.

I'm very interested in testing with the RPi5. Please let me know the results!
luma.core-lgpio.zip

I’ll try and get back into the headspace again to look into this. I’d like to make sure it doesn’t break for existing users, or if it does we can try and manage expectations by publishing a major version. The tldr is to use a more modern GPIO library, right?

@rm-hull
Sorry, but I don't know what "tldr" is.
I wanted to point out that the dependency on RPi.GPIO needs to be addressed. Not only because the RPi5 does not support it, but mainly because the GPIO sysfs is deprecated and has been discontinued. It follows that even existing users of luma.oled are at risk that the display will stop working after an kernel upgrade.
I believe the obvious choice for existing users is to replace the deprecated RPi.GPIO by using the rpi-lgpio library. This requires no modifications (just install rpi-lgpio).
However, for new users it would (in my opinion) be better to skip the rpi-lgpio "compatibility shim" and use lgpio directly. Since @thijstriemstra responded to my notice by renaming and closing my post as duplicate, I tried to make a new version of luma.core myself to test the feasibility of the suggested path. Of course, my solution is not comprehensive enough, it certainly needs to be improved.
I myself have already come up with one shortcoming that bothers me. This is the problem that in the solution I presented it is not possible to use physical pin numbers (BOARD mode) but only GPIO numbers (BCM mode).

In the attached file, this is already solved by adding the "board" parameter. If this parameter is omitted (or set to False), BCM mode (native to lgpio) is used. If True, BOARD mode is used.

luma.core-lgpio-2.zip
serial4.py - like serial.py, but uses lgpio and standard spidev
serial5.py - like serial.py, but uses lgpio and SPI, implemented in lgpio
test4.py - test, using serial4.py and mode=BOARD
test4B.py - test using serial4.py and mode=BCM
test5.py - test using serial5.py and mode=BOARD
test5B.py - test using serial5.py and mode=BCM

The decision seems to have been made to replace RPi.GPIO with lgpio. In my tests, this has worked without any problems so far.

However, I would like to point out that it can lead to unpredictable complications in existing projects if lgpio does not behave 100% like RPi.GPIO. We all know that such a match is virtually impossible.

gpiozero, on the other hand, can be installed from the debian repository since buster and is one of the packages installed by default (at least in bookworm). Replacing RPi.GPIO with lgpio could be a serious intervention in the system. Switching to gpiozero would avoid the risk of the complications mentioned above and presumably increase stability.

@outdoorbits I don't really understand your objections to lgpio. According to my information, gpiozero depends on lgpio and doesn't work without it. So it is illogical that switching to gpiozero could somehow increase stability compared to a solution that omits gpiozero.

It's just because you have to remove RPi.GPIO and this looks like a bigger change to the system than keeping such a central package untouched.
For me both solutions are fine, in my project they are working. I even removed my changes to luma-core and switched to lgpio to stay compatible with future luma-core versions.
In my project I have the display (luma / lgpio) and some buttons, controlled by gpiozero. Both are working very well at the same time. This was just a general strategic consideration.

I even removed my changes to luma-core and switched to lgpio to stay compatible with future luma-core versions.

I am not sure that your steps are not hasty. I do not yet see that @rm-hull or @thijstriemstra is preparing to switch to lgpio in the near future. And in the more distant future, anything is possible, for example, that some other solution will appear.
The fact that RPi.GPIO is obsolete and that it is even unsupported for RPi5 is a reality. So controlling buttons with gpiozero is a pretty obvious choice. However, if you look at the lgpio documentation (there are also examples - for example GPIO Monitor), you will find that you can control the buttons directly with lgpio and even in this case you can skip gpiozero.

I am sorry that I will answer to myself. But what to do when no one else is discussing here and I feel it's important to add some additional comments.
I found that my proposed concept (that is, skip the RPi.GPIO layer - or its replacements - and use lgpio directly) can be of great benefit to many other potential users of the luma.core library.
I mean owners of SBCs other than Raspberry Pi. Of course, RPi users have an advantage, because in their case the lgpio library is installed as part of the operating system (bookworm) already in the base.
For other manufacturers (such as Allwinner), lgpio must be installed. But as I have tried it myself, it is not difficult.
The installation procedure is described in detail on the page https://github.com/joan2937/lg. At least in the case of my Orange Pi Zero 2 board (Allwinner H616) it went quite smoothly.

However, while testing luma.core and luma.oled on the Orange Pi Zero 2 board, I realized that the modifications to the "serial.py" module I suggested last time still need some work.
There are two problems here:

1. Obtaining the chip number
2. BOARD mode - getting the gpio number from the physical pin number

Obtaining the chip number
You need to know the chip number for lgpio to function properly. In the previous version of my modification of the "serial.py" module, I used the "_get_gpiochip_num()" method, which I took from the rpi-lgpio library, to get the chip number. But it only works for RPi type SBCs. Another way must be found to make this work for other manufacturers' SBCs.

Getting the gpio number from the physical pin number
In the previous version, the mentioned conversion also only worked for RPi boards. Another way must be found to make this work for other manufacturers' SBCs.

As a solution to both problems, I introduced a new "model" parameter. However, the database of individual SBC models must become part of the luma.core library. The database contains both a conversion table and a chip number for each model. The database is in the "sbc.py" module. So far (for testing) it only includes RPi4, RPi5 and Orange Pi Zero 2 boards. The "sbc.py" module needs to be placed in the root of the luma.core library (like "device.py" for example).

In the attachment there are again two alternatives of the "serial.py" module. ATTENTION, this time I tested with an Orange Pi Zero 2 board (DC is connected to pin 13 and RST is connected to pin 11) and the test programs match this!
luma.core-lgpio-3.zip
sbc.py - test database (only contains RPi4, RPi5 and Orange Pi Zero 2 boards)
serial6.py - like serial.py, but it uses lgpio and standard spidev
serial7.py - like serial.py, but it uses lgpio and SPI, implemented in lgpio
test6.py - test, using serial6.py and mode=BOARD
test6B.py - test using serial6.py and mode=BCM
test7.py - test using serial7.py and mode=BOARD
test7B.py - test using serial7.py and mode=BCM

I am asking for comments on my post !