Detecting keyboard state in shell
A discussion happened recently and a need was raised to detect key states (whether a certain key is pressed) in shell, see here http://bkhome.org/blog2/?viewDetailed=00238 (second comment). So I went googling for a while, found the answer here: http://stackoverflow.com/questions/3649874/how-to-get-keyboard-state-in-linux and tidy it up a little bit, as attached.Usage: kbstate key [devpath]
Returns: 0 if key is pressed, 1 otherwise, 255 for errors.
key is either lshift, rshift, lalt, ralt, lctrl, or rctrl (that's left/right shifts, left/right alts, left/right controls) in English keyboard, not sure the equivalents in others. If you hack the source you can easily check for other keys too.
devpath is the path to the Linux's keyboard event device. The default value is /dev/input/by-path/platform-i8042-serio-0-event-kbd (that is, the built-in PS/2 keyboard) but most of the time you would specify /dev/input/event5 or something. Scan /proc/bus/input/devices, find a device whose handlers is "kbd", and you know which /dev/input/eventXXX you need to specify.
If you need to test multiple keyboards (PS/2, USB, etc) you will need to call kbstate multiple times, one for each devpath.
Get the source, 32-bit static binary and 64-bit static binary.
Comments - Edit - Delete
guess_fstype from busybox
guess_fstype is a small utility to - well, "guess" the "filesystem" that resides in a given block device. It is used extensively in Puppy Linux and its variants including Fatdog. Its job is so important that if you have a malfunctioning binary then most of desktop filesystem operations will cease to work correctly.guess_fstype was originally cobbled from guess_fstype_* functions from mount.c in util-linux (long before util-linux had blkid), it came from the same set of functions which powers "mount --guess-fstype" (which also gives the binary its name).
Over time, more and more filesystem type detections got added, and the code becomes more and more messier. It still works, and it still works beautifully, but it is not easy to maintain. So I began to search for a replacement.
klibc
klibc has an explicit standalone "fstype" binary, which is used to do exactly what guess_fstype does (but its output is different). It is small and fast and static - it's a good candidate. Unfortunately, its repertoire of filesystem detection is less than sterling - it lacks popular filesystems such as FAT and NTFS. While it can be patched to add those two, the point of my exercise is to try to *not* to maintain the detection code myself.
busybox
I turned on to busybox, which also has filesystem detection code. As it turns out, it is relatively easy to use them for a standalone application, and to my delight they are rather complete too. So I created a patch that will create a guess_fstype-equivalent from busybox.
To use the patch:
1. Extract vanilla busybox 1.21 source
2. Apply the patch (get it from here)
3. Go to the volume-id directory
4. Type "make"
5. You will end-up with a bb_guess_fstype which can be renamed to guess_fstype for proper use.
Busybox's guess_fstype recognises less than the original Puppy's busybox, but I don't think this is a problem as what it lacks are "exotic" filesystems anyway (everyone ever user xiafs recently?
) and would be very rarely used, if ever, indeed.
You can fine-tune the filesystem to detect by editing the fake_libbb.h (removing the defines) as well as the Makefile (removing the object code from being linked in).
When new version of busybox is released, all that I need to do is to update this patch. There will be no need to separately maintain the filesystem detection code anymore. As for now, I actually included the f2fs filesystem detection code in the patch, but as soon as this is supported by busybox natively, it will be dropped.
This new guess_fstype will be in the next version of Fatdog.
Comments - Edit - Delete
Testing LF preloader
Okay, I have played with Linux Foundation's preloader for a short time. It currently doesn't play nice with Matt's shim - shim requires signed binaries; while preloader (in its current state) does not accept signed binaries
The good thing is that they are working on it.Comments - Edit - Delete
Linux Foundation Secure-Boot compatible UEFI boot loader released
We have been using Matt Garret's shim since last December for our Fatdog64 testing purposes. Our general feeling is that while it works (and it works well), it is not user-friendly.Linux-Foundation's UEFI PreLoader fulfills the same function and needs are shim; and from what we can see it may be a bit simpler for those who just bypass Secure Boot (as opposed to shim, which intends to use Secure Boot to make Linux boots securely). But while it was conceived first, its release was delayed - shim got released first and that's why we use it.
But the news is in: It has been released!. This is good news, and we will probably play with it for Fatdog64. However, as Fatdog64 is so close to beta, we will have to make a decision whether to postpone beta or postpone the testing with the preloader.
We will see. Either way, Matt said that he and James Bottomley (the one who did the preloader) are planning to combine effort and merge their works. Meanwhile, let's just celebrate that we now have two alternative ways of working with Secure Boot machines. Ah, the joy of open source
Comments - Edit - Delete
