Search this site

[prev]  Page 3 of 3





new moused progress

I spent the last two days working out the prototyping ideas for the new moused. So far I've got a decent plugin framework with two plugins written currently. I've been using this new moused since yesterday with much success.

moused.c is 280 lines (will likely be less when finished)
the sysmouse module is 160 lines and supports ums(4) and psm(4) mice

The old moused.c was over 3000 lines long. The existing psm(4) is well over 3000 lines. I don't anticipate my moused ever being over 300 lines of code. The plugins will be doing the meat of the work. I'm hoping to make the plugin api good enough so that plugins will only have to know how to talk to their specific hardware and let moused worry about talking to sysmouse(4).

Right now there is a potential for writing some filter modules becuase of the way the plugin api is designed. Filters would be used for such things as emulate-3-button and virtual scrolling (-3 and -V respectively). I already have a filter written for virtual scrolling. Compared to the hackery I had to throw into the old moused to get virtual scrolling working, this was an absolute breeze to write. It is simply a function called 'filter' that understands what virtual scrolling is and when to do it. Filter is called before any updates are pushed to sysmouse.

The next big job is going to be stripping psm(4) of it's bloat and making it an almost a pass-through device. The non-standard mice it supports currently (synaptics, etc) will be supported through plugins in the new moused.

If you're interested in helping me test this, let me know.

newpsm updates

I got around to publishing a writeup on my ideas and progress on my latest project to reengineer the mouse framework in FreeBSD. Assuming it gets finished, it'll probably end up in FreeBSD 7.x. I've been working with one of the freebsd committers ([email protected]) bouncing ideas around and such. I think the plans I've got are fairly solid despite my lacking hardware/lowlevel programming experiences. The existing mouse code is fairly easy to read so I'm using that as a starting point for learning. I won't bother reiterating what's already on another page, so if you're interested in telling me I'm completely wrong (or suggesting features, or just reading for fun), then go on over to projects/newpsm

Link: projects/newpsm

Adventures in Kernel-land

Having found myself with a lack of energy for working on my current projects, I decided to start a new one. This one aims to be a flexible input-device framework for FreeBSD.

I know next to nothing about the kernel and it's implementation, but fiddling around so far I've done somewhat well-ish. The first thing I'm going to do is make a new psm driver that can be loaded as a kernel module instead of having to be built into the kernel. My first target is going to be a driver that supports generic PS/2 mouse devices.

Once that's working, I'm hoping I'll be well versed enough in kernel development to actually start working on a framework for input devices (keyboards, joysticks, and mice). I'd prefer that things like special mouse drivers for things like Synaptics touchpads are off in their own little sub drivers. I also want sysctl tunables for options that are reasonable to have changed.

Right now, I'm not sure how I'm going to implement this framework, becuase I simply don't know enough about the kernel to know how to do it properly. More on this as things develop. This should be a fun project for me seeing as how I've never really dealt with hardware before, nor have I ever written anything on the kernel level.

soekris adventures

So for this new part-time job I've got, I'm working on a Soekris net4501. FreeBSD has some surprisingly cool support for these things thanks mostly to [email protected]'s work. Now that I've managed to get a slimmed down version of freebsd built and running (7.3meg world, 2.2 meg kernel) of a pxe boot, I've had a chance to actually play with the darned thing.

The first thing I noticed was /dev/led/error. You can do

echo 1 > /dev/led/error

and viola! The error led on the board is on. This device supports quite the array of syntax you can throw at it. For instance, I can do

echo "f1" > /dev/led/error

and the error led will start blinking. Read led(4) if you care to know more about the rest of the syntax it supports (it'll even handle morse code from running /usr/games/morse -l).

I also discovered there was support for the GPIO pins on the board, too. This is done through the same /dev/led interfaces. To enable one of the pins as a device, you fudge around with the machdep.elan_gpio_config sysctl and you'll end up with devices such as /dev/led/gpio5. Neato! More about the GPIO-specific stuff here:

So far so good, I've got a usable shell with most tools I use (short of gcc and gdb) in 8.7 megs.

# df -h
Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/md0       19M    8.7M    8.8M    50%    /

Since it's less than 10 megs, I have it mounted in memory instead of nfs. Doesn't hurt too much, seeing as how the board has 64 megs of ram, and with everything booted and me logged in I have 26 megs free.

Speaking of disk size, /usr/bin/host is a whopping 1.1 megs. That's quite large for dynamically linked binary. However, I think it was statically linked against libbind or something silly. Either way in the final product it'll go away, shaving more disk usage off.

This project has been a grand adventure into freebsd's world build system. My whole time working on this has been me writing one makefile. The way it works is fairly slick, I think. First, it generates a 20 meg vnode-backed filesystem, then builds a bunch of things from /usr/src and installs them to that new filesystem. Once this is done, I clean out some unnecessary files like library archives (.a files), worthless things in /usr/share, etc. The kernel is handled much in the same way, doing make buildkernel in /usr/src and then plopping a new kernel.gz in /tftpboot.

The cool part is how libraries are built. The makefile builds all the necessary binaries, installs them, and then uses ldd(1) to look for library dependencies. With this list of required libraries, it builds each required library from /usr/src and installs those. To make things easier to work with, I have two other make targets that let me test the system in both a jail(8) and chroot(8). This soekris board is so cool :)

FreeBSD moused patch

I made a patch for freebsd -current's moused that lets you scroll up and down while holding the middle mouse button and moving the mouse up and down. I found this feature in windows on my laptop extremely useful, perhaps others will now aswell in FreeBSD.

The patch is available aswell as the patched source (which may or may not work for you).
Usage - Copy the source or patch to /usr/src/usr.sbin/moused. If you got the patch, then do patch < moused-patch. Run make all install and it should build it and install it for you.
Two new options are thus added to your moused: -V and -U. -V enables virtual scrolling and -U with a number parameters specifies the distance threshold (defaults to 5) before a scroll tick happens.

dhclient and dhclient-exit-hooks

Using DHCP on resnet only gives me search as far as search domains. So, I got bored and wrote a small script to add useful domains for me. This is done using a feature of ISC's dhcp program, dhclient, called dhclient-exit-hooks. This is a shell script that is run when dhclient finishes fetching you an IP address.
This will add and to the search line in my /etc/resolv.conf.
Requires: a version of sed that supports inline editing (the -i option)



for dom in $DOMAINS; do
        grep "^search.*\b$dom\b" /etc/resolv.conf > /dev/null 2>&1 || 
        sed -i -e "/^search/ s/$/ $dom/" /etc/resolv.conf