qi-hardware/iris
1
0
Fork 0
mirror of git://projects.qi-hardware.com/iris.git synced 2025-04-21 12:27:27 +03:00
Code Activity

make keyboard work a bit

Browse Source
This commit is contained in:
Bas Wijnen
2009-07-27 20:03:58 +02:00
parent 283b97955d
commit 561535234d
9 changed files with 454 additions and 60 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
report/making-of.tex
View File

@@ -578,4 +578,70 @@ Because this didn't feel good, I decided to implement the timer interrupt
first. I copied some code for it from Linux and found, as I feared, that it
didn't give any interrupts. I suppose the os timer isn't running either.
However, it wasn't as bad. I simply had a bug in my timer code; the OS timer
does give interrupts. Checks to see the random register also showed that while
it doesn't run as required by the mips specification, it does auto-increment as
part of the \textit{tlbwr} instruction, which is for practical purposes just as
good (but, I suppose, costs less power).
So the only clock that isn't working is the cpu counter. This means that the
operating system timer must be used for timed interrupts, and that works fine.
After rereading the Linux driver for the display, I also found several things I
had done wrong, and after fixing them it did indeed work. The display
controller reads its data from physical memory, which means that the entire
framebuffer needs to be a continuous part of physical memory. I had to create
a new kernel call for this. Like the other priviledged calls, I added it to
the Thread capability.
\section{Debugging made easier}
So far, all debugging had to be done using blinking LEDs. This is slow and
annoying. With a working display, that was no longer needed. I added a simple
($6\cross8$) character set, and implemented a way to let the kernel send
messages which are printed on the screen. Then I changed the response to a
\textit{break} opcode to result in sending a character to the lcd as well. Now
I have a textual log output, which is much better than blinking LEDs.
Shortly after this, I encountered a bug in the kernel allocation routines.
This still needed to be debugged with blinking LEDs, because allocation was
done as part of sending messages to the display driver. This was annoying, but
now that's done as well and the text log can be used.
\section{Keyboard}
The keyboard driver works mostly as I expected it to. I added interrupts on
any change, so that it is quite normal that key changes are detected by
interrupt, which is faster than waiting for a scan. I would like to use
level-triggered interrupts, instead of edge-triggered. However, at the moment
that doesn't seem to work. I don't really care for now, although this may lead
to missed keys, so it is something to fix eventually.
\section{What is a terminal?}
Now's the time to think about more high-level features. One feature I want to
have is that a user has a session manager. This session manager can have
access to the terminal. And it can lose it. And get it again. It gets access
when the user logs in, and loses it when the user logs out. Having access
means being able to use the hardware (display, keyboard, sound, etc.). The
problem is mostly with losing the display. Getting access to the display
happens by mapping the pages into memory. The user can then share these pages,
and it will be impossible to revoke the access.
But there is a simple solution. The session manager itself is part of the
system. It is trusted by the kernel, and will behave. It will do anything the
user asks, as long as the system allows it. Each session manager can have its
own frame buffer. This is even a good idea: it means that user programs will
not have to handle things differently depending on whether the framebuffer is
available: it is always there, it may just not be visible for the user. Then
the rest of the problem is for the user to solve. The user may mess up their
own display if they want. It will not harm the main control display (used by
session managers and the login manager), or displays of other users.
\section{Defining interfaces}
The next programs to write are a \textit{block device} (the mmc and sd card
driver, or else a ramdisk), a file system, the session manager, a keyboard
translator (interpreting modifier keys and implementing key repeat) and some
sort of shell. These are more device \textit{class} interfaces than simply
interfaces for these specific devices. So it's good to design an interface for
the class, which allows other devices of the same class to use the same
interface. Then higher level programs can use both devices without noticing.
\end{document}