Contributed by johan on from the microsoft-owns-us-all dept.
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.
Thank you for a very interesting read and for your work on ACPI, this will benefit a lot of users.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.
(Comments are closed)