Project dead

[bmuessig]

So you want to tell me there is no need for this project anymore?!?! This is the second most useful resource for the Raspberry Pi (aside of wiring pi) when it comes to interfacing things. The DRM version is a joke so far (one device implemented) and this is now dead. Great, what a great job!

All sarcasm aside, I would be willing to help work on the other project, especially because I need the ST7565 display to work ( https://github.com/zanaster/fbtft/blob/master/fb_st7565.c )

[notro]

fbtft is a dead end in the sense that it won't be moved from drivers/staging/fbtft to drivers/fbdev/fbtft as the intention was. The fbdev subsystem was closed for new drivers some months back. The code in drivers/staging/fbtft will stay until there's a drivers/gpu/drm alternativ available.

Greg Kroah-Hartman still accepts patches to drivers/staging/fbtft, but I'm not working on fbtft code anymore. Just answering questions.

I was hoping to have a drm version up and running by now, but the drm subsystem is a complex thing that has taken some time to understand. I'm now exploring the possibility to have drm userspace drivers. This would make it possible for anyone to write a driver. The reason I look into this, is that Device Tree policy dictates that we can't have an initialization sequence in a property like fbtft does. This means that there will be one driver per display (or init sequence). Which amounts to a lot of drivers.

The question still to be answered is, can I get the same framerate from userspace?

[bmuessig]

@notro Interesting. Thanks for clearing up my misunderstanding. However I still don't think this should be simply abandoned. After all it works fine and is infinitely useful on the Raspberry Pi. Seems like the Kernel community is quite harsh, bummer!

DRM userspace drivers, interesting. I assume the frame drop will be significant from all the permission context switching. But I can just assume as I don't know too much about the Linux kernel.

How feasibly is it to still use fbtft with the custom device I mentioned above nowadays? Has fbtft broken the API since September, 2013 or should it still work? Also I just want a simple text based TTY, so it should be easy, right?

[alidaf]

@bmuessig It shouldn't take much to modify that driver to work. I have managed to get the ssd1322 to work with some help from notro. I've written a wiki with the steps that I used for the ssd1322 and you may find it helpful to get yours working. It's mostly based on notro's guides but consolidated and clarified in places, although still work in progress.

[notro]

Seems like the Kernel community is quite harsh, bummer!

It can be, but in this case it's just a new graphics subsystem taking over from an old and outdated one. Maintanence takes manpower, and no one capable is willing to maintain a duplicate subsystem. drm is now simple enough to write drivers for, so it's a waste spending time on fbdev.

DRM userspace drivers, interesting. I assume the frame drop will be significant from all the permission context switching. But I can just assume as I don't know too much about the Linux kernel.

The spi transfer of the video memory is what takes almost all the time during a scanout. Usually a userspace driver would have to copy the buffer from/to the kernel addres space, but dma-buf provides a way to pass a buffer as a file descriptor, bypassing the need to copy the buffer. This is what makes me optimistic about the userspace driver approach. And for drivers that needs to massage the content before sending it to the display, it's possible to mmap this fd, but that seems to be slow.

[mrmowgli]

Interesting, so for newer kernels everyone is being asked to develop for DRM instead? But the DRM has to happen in userspace, or is that just to make things simpler? For older kernels though this driver should still be relevant. I'm actually interested in writing a driver for an unrelated SPI screen on a different arm platform, so how useful would this repo be as an example for that?

[notro]

DRM is like fbdev a Linux kernel graphics subsystem. I briefly looked at userspace drivers, but gave up on that.
tinydrm (fbtft replacement) will hopefully be merged soon: [PATCH v4 0/7] drm: Add support for tiny LCD displays

If you're writing a standalone driver outside of fbtft, then I don't think fbtft is a good example. It's quite convoluted.

http://elinux.org/images/1/19/Passing_Time_With_SPI_Framebuffer_Driver.pdf http://embedded-webkit.blogspot.no/2013/05/baby-steps-to-writing-linux-lcd-driver.html

[mrmowgli]

Thanks for answering this question, I realize now that the best source of information are the kernel docs. Is there a reason why you decided to avoid the userspace drivers?

[notro]

Is there a reason why you decided to avoid the userspace drivers?

Because of the feedback from a drm maintainer: https://lists.freedesktop.org/archives/dri-devel/2017-January/128790.html

[notro]

Closing issue since there has been no activity for more than 2 months. Reopen if needed.