notro / fbtft

Linux Framebuffer drivers for small TFT LCD display modules. Development has moved to https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/fbtft?h=staging-testing
1.84k stars 495 forks source link

how to passing device specifc command to OLED/TFT display #531

Closed rudiratlos closed 2 years ago

rudiratlos commented 5 years ago

I can use my OLED (SSD1306) via /dev/fb1 and console /dev/tty1 everythings works (lke drawing a line or a cirlce...)

But how can I pass device specific commands like scroll on (0x2f),scroll off (0x2e) ... ?

notro commented 5 years ago

You can overrride the whole display controller initialization using the fbtft_device init= parameter.

Docs: https://github.com/notro/fbtft/wiki/fbtft_device#parameters Driver default init: https://elixir.bootlin.com/linux/latest/source/drivers/staging/fbtft/fb_ssd1306.c#L31

rudiratlos commented 5 years ago

I want to pass device specifc commands during application runtime. not at module load or application startup. I don't want to override the initialization code at all. just passing tiny commands that are really device specfic (like scroll on/off, display brightness, if there is command avail). writing directly to the spi device is not possible (blocked by the OS?)

CRImier commented 5 years ago

same idea here. It seems to me that this is not currently possible, unless we were to implement a fbtft core "extension" of sorts, based on i.e. debugfs. I should read the code more, of course, maybe there's already such a thing - but I doubt it.

notro commented 5 years ago

I want to pass device specifc commands during application runtime. not at module load or application startup.

That's not implemented in fbtft.

rudiratlos commented 5 years ago

ok, understand. Is it possible to directly access to spi device to send device specific commands. As I understand, the spi device is locked (mutex-/spinlock?) by the OS? How to bypass this?

notro commented 5 years ago

The spi device tells Linux what's connected and the driver provides the functionality to drive that device. You need to hack the driver if you want custom functionality.

You might get away by using pin muxing to switch the pins between 2 SPI controllers or between 1 SPI controller and a gpio emulated SPI controller, but I don't know if changing the muxing will produce gliching on the pins. Not recommended.

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.