New Linux Driver- Looking for wanted features


New member
Greetings to all!

I've recently thought that Linux could benefit from a easy to use driver/control program for the Crystalfontz series of displays (USB and Serial). I've tried using LCDProc before, however, it is very complex, and while most Linux users can set it up, I think it would be far easier if there was a program that had a nice X11 GUI to it.

I just wanted to see what you all think about my ideas here, post any features you'd want to see for the LCD if you want to!

First- the GUI would be modelled after CrystalControl. Simple, and powerful. I don't know if CrystalControl has Keypad support- but it would definately have to be a must. A form of simple Menu designer would be useful (I think anyways) too, for maybe using the below feature.

Second- For any features that aren't available already in the program, users could write simple "modules" with some form of a well known Syntax that is easy to learn (I thought C++ was fairly easy to grasp the basics, although that was a few years ago when I first started). The modules can do whatever they want; they are saved somewhere and can be used at will under the Control GUI. The modules would all follow a standard "output" to the Control program to make things easy.

Third- Purely asthetic, but I would be seriously tempted to put in some options for Eye candy- like Screen changing, idle animations, Custom animations even for those that want to do so. Even some custom animated icons for the LCD Screen also.

Forth- Custom charactors.

5th- While I think that it is possible to write some form of a kernel driver/module for the LCD's, that is sort of overkill. I think there was a program out for Linux that made the LCD showup as /dev/lcd, but, I think it would be far easier if the GUI program had some form of a daemon that dealt with controlling the LCD instead of messing with the kernel.

and 6th- Some form of again, a Module like plugin for the GUI interface to make things easy for premade modules.

I'm sorta leaning towards a GUI interface as I said like CrystalControl, but also somewhat like LCDC.

Let me know what you think- and of any other features you might want!

Keven Tipping
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

CF Tech

Wow! That sounds like quite a project.

In case you were not aware of it, there is also LCD4Linux:

Another option might be to develop a GUI front end for LCDproc, then you would not have to completely re-invent the wheel :)


New member
Thanks for the reply.

I have indeed seen LCD4Linux- but as far as I know, it doesn't support the thermal features of the Crystalfontz displays and the keypad buttons- on the thermal monitoring and Fan control, I don't think LCDProc supports those ether.

I could write a GUI for LCDProc- but, I think it'd be easier to just write everything from scratch.

The one thing I'd like to achieve is just a simple installation- download your RPM (or .pkg, .tar.gz, whatever your Distro would use), install it, run the Executable, setup your LCD information and such, and start to design your own LCD displays (all with a GUI of course :) ). And if it only supports Crystalfontz displays- right there- I wouldn't have to worry about other display support such as Matrix Orbital (blah) and the other hundreds of different LCD's out there, making development much easier.


New member
Sounds really neat. I am primarily interested in controlling fans, and doing temp status display, while preserving the 'failsafe' functions of setting all fans to full speed in case of communication failure, and shutting down in case of over temp.

Since reporting temps, fan speeds, etc. might be more data than can comfortably display on one screen, I'd like the buttons to be useful for manually selecting what data to display. (W/ automatic display at other times)

I think that your program should also have two modules, one being the GUI configuration module that mostly doesn't need to run, and a second module that takes the data from the first and does the actual work. This second module should ideally be as small as possible so that it would require as little in the way of system resources (RAM, CPU cycles, etc) as possible.

Keep us posted on your progress.