Developer Blog - pirofti@: The ACPI dance

Lately there's been a lot of action going on in OpenBSD ACPI land. Things are slowly moving towards ACPI resume and suspend. Developer Paul Irofti (pirofti@) recaps on some of the changes while he also blogs about his first general hackathon and his experiences during it.

Before I left for c2k9 I made sure I'd get as many ports updated (including
as much of the ruby-* family as I could) so I could concentrate more on kernel
coding.
Sure I planned on working on wine too with ariane@, but she was too busy with
kernel stuff as well, so I ended up doing mostly ACPI all hackathon long.

As soon as I arrived I started meeting new people and associating names with
faces. I was looking forward to meeting the ACPI people that I worked with for
the last year. They were all sitting at a table. So I quickly squeezed in
between them and started talking, asking, learning, hacking all day long.

My first objective was to get the stuff I had been working on into the tree. 
This had to be done carefully as it had to be integrated with the rest of kernel
and user land in an elegant manner.

So I resurrected my old acpivideo branch and strated cleaning it up, fixing or
optimizing bits and pieces, the works. Then I went on to integrate it with
wsconsctl(8). This was new territory for me but luckily I had miod@ to beat to
death about it. I think we must have passed dozens of mails until I was able to
get it to do it the proper clean way. And each time I learned something new
about it and I must say wsconsctl(8) kind of grew on me!

After the diff was pretty much in a good shape I started testing it. The
great thing about being at a hackathon is the large hardware collection you
have access to. I was jumping from one laptop to another testing if I got
brightness keys events, if the wsconsctl hooks showed up and worked correctly, if
the dmesg for all the output displays was there etc.

To my great surprise the majority of the laptops worked. The Thinkpads were an
exception as they call a magic CMOS method to set the brightness level and at
first the acpivideo driver took over those events and so these laptops were all
of the suddenly without brightness control capabilities. So I had to detect if 
we're running on a thinkpad or not and enable acpivideo accordingly. Later on I
got the two drivers to coexist in peace but this hasn't got in yet as more
testing is required.

After some more cleaning and KNF-ing my diff got in and we had acpivideo enabled
in GENERIC. This was great progress for me and got me even more enthusiastic. In
tree there came more fixes and suggestions as people were testing on their
laptops (matthieu@, kettenis@, miod@ and others were of great help). Also users
started reporting that it worked on some laptops that I didn't have access to
there.

The next part for acpivideo was output switching. This was pretty complicated as
the ACPI specification was a bit confusing. For example you could just mark a
device for output switching and later on commit the change. After I had a diff
with lots of debugging output and a bit of heuristics that made sure all the
outputs were handled and called when an output switch event was received, I
found, to my surprise, that almost none of the laptops implemented this. Most of
the acpidumps contained empty methods or NOPs. So this did not get in as it only
added dead code. I plan to send out the diff for testing in the near future to
see if someone can really make use of this. Until then I'm thinking of removing
the ACPI request to the BIOS that tells it to relinquish output switching
control to the OSPM.

The next code I had lying around in my tree was for ACPI power resources. A
power resource can have multiple clients that depend on it for power control.
This is very useful for suspend/resume and jordan@ already had been working on
some code that required this to be implemented. So I cleaned up the bits I had,
created a separate driver for it that could handle events and would allow
clients to register to it. This went in too after it got the necessary okays 
and is waiting now for Jordan love.

It was too bad that marco@ and jordan@ had to leave early because of work. So
mlarkin@ and I were the only ones left at the ACPI table surrounded by
laptops to test on. Most of my bits and pieces were happily in the tree now. So
I asked mike if I could help. He had a list of three things he should do before
going further with suspend/resume. One of the points in the list was a big
scary diff for a 16-bit emulator that would do VGA reposting on resume. The
others were pretty specific to what he was working on and I would just get in
his way if I attempted to work on them. So onwards to the ugly diff I went.

oga@ had done most of the work of ripping the important parts from the NetBSD
tree. He and matthieu@ needed this functionality for X too. So I asked him to
mail it my way. It was a 10k liner. Scary at first but then I realized that half
of it were just comments. Sometimes a comment would be longer then the 3 line
function it was describing. I applied the patch and started testing. The cool
thing was that we had a ddb callback function for it that would ease the testing
process.

Soon we found out by printf-ing the hell out of it that the endianess was not
properly done. So I fixed that quickly by assuming this code will only run on
i386 and amd64, which was true for ACPI. Later on big endian architectures could
be handled by ifdefs, which actually happened after theo and drahn spend some
time making sure everything was handled properly with me and mike popping up
now and then to comment.

I got bitten by the debug messages because those would take execution time, 
and time was very important for that part. So what the code did was to read a
chunk of the BIOS code where we knew the video part would be and pass it on to
the emulator so that we would POST the video again. As the emulator went on
through each 16-bit instruction I would print it. And reposting wouldn't work. 
As I got used to the code I turned off the messages so I could make the testing
process a bit faster. And what do you know, the code was working! I then 
realized that all this time I was delaying the process with printfs and screwing
the time dependent parts of the process. I then cleaned the debugging stuff and
went on to test. Every i386 that I got access to worked. amd64 was a different 
thing, most of them worked but some would just fail to repost or do all sorts of
strange things. 

Theo suggested that I'd get this in and work on it in the tree. And so I did
after a bit more cleaning. So this was in too, during this time mike was always
there to help but also taking care of his part of the suspend/resume. So the
next day he got very close and resume worked in some regards. Meaning that the
laptops came back from suspend but the drivers needed to handle this special
event somehow too or otherwise you'd get back online without a keyboard, or a
hard drive or or or... So Theo and Mike were in there for a whole day figuring
out how to do it properly, when to do it, what hooks to use and so on. But that's
a story for them to tell.

Of course meanwhile all sorts of non ACPI related stuff happened, like talking
to Theo and getting tmux in and nicm@ an account, learning about how stuff
should be done correctly, getting to listen to lectures or rants from other
people (hello bob!) about their parts and thus learning a thing or two, seeing
henning@ mailing diff backups to random people after he lost half a day's work,
watching robert@ struggle with yet another big port (I'll let him tell you about
it) and watching everyone working hard and passionate. This was really
inspiring and the atmosphere there was just great! At the end of the day we
would go out for beer and, guess what, we'd still be talking about hacking and 
sharing ideas and thoughts about stuff throughout the tree and then, when
the bartender would kick us out, we'd go back to the hacking room and continue.