R5 Development Environment?

I have a Fujitsu P1120 laptop, upon which BeOS R5 runs great. The sound gets a bit choppy, and VLC can’t quite keep up with playing a DVD, and ACPI does not work so battery level and system shutdown don’t work, but other than that, almost all of the hardware works.

There are two pieces that do not work The built-in Winmodem, which I don’t really care about, and the touch screen.

I have never written a driver before, on any platform, but I’d like to give it a shot. Under Linux, I have written a program that reads from /dev/input/event# that successfully reports when the user has clicked the touch screen, as well as the X/Y position of the tap.

The device is a simple HID. When I touch the screen, the cursor moves, although not to the intended location. Click events are registered, but the device seems to be reporting to Be in an unexpected manner. The end result is that the cursor twitches at the bottom of the screen, rather than tracking the actual tap location.

Given this scenario, it seems ripe for the creationg of an InputServerFilter.

Unfortunately, I cannot seem to create one.

According to ‘gcc -v’, I am running ‘gcc version 2.95.3-beos-041202’. Unfortunately, I cannot seem to create a file that BeOS is happy with. I am able to compile the sample code located in /boot/optional/sample-code/input_server/, but whenever I copy the resulting .o files into ~/config/add-ons/input_server/(drivers|filters)/ and restart the input server with /system/servers/input_server -q, the input_server crashes. I then need to restart, disable user add-ons, remove the file, and restart again.

So, I have two questions.

The first How can I restart the input_server again without performing the restart two-step? If I’m connected to the laptop via ssh, running /system/servers/input_server -q again after removing the add-ons doesn’t seem to bring the system back to life.

The second How can I develop working input_server add-ons? Given that I’m using Be’s compiler and compiling their sample code, what are the magic incantations? Or do you suspect a misconfiguration in my system?

As an aside, if this is not an appropriate place to post such questions, I apologize, and will look for somewhere more appropriate to ask for help.

Without actually having a BeOS system in front of me I’d say that you’re problem would be with copying over the object files. The input server (along with pretty much everything else BeOS related) needs a fully compiled module rather than linking into the kernel/etc as is the case with Linux, et al. Rather they use predefined entry points into full dynamic libraries. (Hopefully I’m not talking out of my arse here though it is a possibility).

Does any of the sample code work for you? I doubt very much that your system is misconfigured.

And yes, by all means post such questions here, on the mailing list or on IRC. :slight_smile:

I don’t seem to be able to build any input_server modules. When I compile the “nervous” example, which is an actual input_server driver, make performs the following tasks

gcc -c nervous.cpp -I./ -I- -I/boot/develop/headers/be/add-ons/input_server/ -O3 -Wall -Wno-multichar -Wno-ctor-dtor-privacy -o obj.x86/nervous.o
ln -s /system/servers/input_server APP
ar -cru ""obj.x86/nervous"" obj.x86/nervous.o
mimeset -f "obj.x86/nervous"

Does "ar" perform the link? Or is it, in fact, skipping this step?

seancross wrote:
gcc -c nervous.cpp -I./ -I- -I/boot/develop/headers/be/add-ons/input_server/ -O3 -Wall -Wno-multichar -Wno-ctor-dtor-privacy -o obj.x86/nervous.o ln -s /system/servers/input_server _APP_ ar -cru ""obj.x86/nervous"" obj.x86/nervous.o mimeset -f "obj.x86/nervous"

Does "ar" perform the link? Or is it, in fact, skipping this step?

GNU ar is an archiver. Static libraries are just one or more object files in an uncompressed archive, they don’t need linking.

The nervous example should be producing an ELF shared object aka shared library or add on, which requires a separate linking step. For whatever reason that’s not what happens in the output you’ve pasted.

An input filter probably isn’t really the right fix for your problem anyway, but it may be the easiest to implement.

Alright, I found the issue. It turns out SpicyKeys doesn’t react well to the input_server going away. This is what I get for not trying the “empty case” and simply issuing an ‘input_server -q’ on a fresh boot.

I think I see what you mean when you say that an input filter is probably not the best solution. The biggest issue I see is that the Filter() function does not know which device generated the message. So, while I can easily fix it so that the touchscreen works, that would then break ordinary mice.

For now, I’m looking into writing an input_server device, which, for now, seems more promising.