Kronos hacking for a broader audience - Step 1: User Interface

In the last few days, the interest in this kronos hacking has increased significantly. Unfortunately this blog isn't worth much to someone without deep knowledge about Linux and other stuff. And on top of that, there is no structure since I just wrote down stuff as I researched.

Marcan (whom I deeply respect for his work on the Wii) just filled this gap with a very nice blog post that summarizes my research and adds a proper introduction for the beginners as well as some detailed background.

As he wrote in this thread, the possibility to provide feedback and to interact with the user is the foundation for a safe and clean way to bring whatever Kronos modifications we might come up with to a broader and less technical audience.

Fortunately Korg's original drivers provide some basic functionality.

The framebuffer /dev/fb1

The kernel module OmapVideoModule.ko provides a framebuffer device that interfaces the Kronos' LCD display. The resolution is 800x600 pixels and it has to be used in 8bpp palette mode. This means that you can choose up to 256 colors that can be shown on the display at the same time.

Since the display is connected to the NKS4 board, the real framebuffer is on the OMAP. This means that all changes in the fake framebuffer on the PC must be sent to the OMAP via USB. There is a special ioctl (OMAPFB_IOCTL_PIXELREGION) to trigger this update for a specific rectangle on the display. Without this ioctl, you will see nothing on the display. Unfortunately, this means that standard applications that work on /dev/fbX will not work.

There is also a ioctl to setup the palette (OMAPFB_IOCTL_PIXELREGION). Up to 256 palette entries can be populated with RGB colors.

Then, there are some less important ioctls:

• OMAPFB_IOCTL_FILLDATA is an accelerated fill command that fills a rectangle with a specified color
• OMAPFB_IOCTL_GETPROGRESS, OMAPFB_IOCTL_SETPROGRESS, OMAPFB_IOCTL_INCPROGRES, OMAPFB_IOCTL_ADDTOPROGRESS are helpers to draw the progress bar that you see when the Kronos is booting. This progress bar is actually handled by the OMAP so that early boot stages can increment it without knowing about graphics.
• OMAPFB_IOCTL_INITLCDREGS, OMAPFB_IOCTL_XAXISBYTESIZE can be used to configure the LCD configuration registers in the OMAP. As the OMAP configures those registers independently of the PC when showing the title screen, we do not need to do that.
• OMAPFB_IOCTL_GETTITLESCREENVERSION returns some version number that is probably used by the updater to determine where to draw it's messages so that they look nice with different versions of the OMAP software.
  

The keypad /proc/OmapNKS4

The kernel module OmapNKS4.ko creates a proc file that can be used to read part of the control surface (Keys 0-9, Enter, Exit and the scrollwheel). The interface is ugly - you can only read one keypress each time you open the file, but at least it works...

A demo application

I have hacked together a simple demo that shows working framebuffer and control surface access here. If you read through the source, you'll find definitions and wrapper for the ioctls and the keypad interface.