Tuesday, June 19, 2007

FujitsuSiemens TabletPC button module

There is, since some months, a new project to support the buttons of Fujitsu Siemens TabletPCs (T- and P-series machines with FUJ02bf pnp devices) including the 'Application Panel'. The project called fjbtndrv provide a kernel module to get the tablet button and the brightness key events via the input layer (/dev/input/event*).

Additionally, and this is IMO the best, the module catch the tablet rotation event from convertible FSC TabletPCs. This allow us now to detect the state of the tablet (open/rotated-closed) and react on the event e.g. in KDE via KRandRTray and rotate the screen. Together with IBM/Lenovo we have now a way for machines of two major manufacturers to go a step forward with TabletPCs.

I packaged a KMP rpm for openSUSE 10.3/factory. You can download the rpm (fsc_btns-kmp) as always from my home project in the openSUSE build service. The package get later included into the SUSE distribution.

What are my next planed steps to improve TabletPC support?
  1. extend the wacom X.org driver to rotate automatically with XRandR extension
  2. extend KRandRTray to:
    • get rotation events
    • get events from rotate hotkeys
    • allow the user to configure if and how to rotate the screen on these events
Tech Tags:


khnz said...

Hi Danny,

thanks for packaging.
Is someone working on krandrtray, to implement this features (or is there a plan how to do is)? Your next steps are on my todo list too.


Danny said...


I work on the features in the next two weeks and maybe on aKademy, depending on how much time I find to work on this.
First step is change the wacom driver. Have already taken a look at the code, but need to add the needed code at the correct function ;-)

khnz said...

Thanks, sounds good. If there is anything I can help, feel free to contact me.

divide said...

Isn't the xrandr thing trivial to do with KHotKeys?

khnz said...

True for key events. But X doesn't know switches, so you need dbus/hal to ask for it.

Divided Mind said...

Oh, I thought rotation events generated keypresses. Well, if they don't, perhaps they should -- it feels a more standard way than reinventing the wheel and could be readily used by just about any environment. But then again, maybe it shouldn't, and couldn't. I'm just wondering.

Danny said...

You have to differ between the event from the hardware (1) if you rotate the display 180° and close it and the event from the "Application Panel" which is a normal hotkey (2).

What I plan do to in KRandRTray is cat the (1) event (on IBM/Lenovo X-Series TabletPCs we get two ACPI event for this, and we can check this also via HAL) and let rotate the screen automatically depending on what the user configured in KRandRTray. This should be similar to what the tools under the Windows XP TabletPC Edition provide.

Additionally I would map the (2) Hotkey event to rotate the screen 90° or 180° (maybe make this configurable also in KRandRTray) directly.

khnz said...

Key events can only represent a change, not the state of the display (unless you want a permanent pressed key). But a tool should "known" the state of the display rotation, so it can always switch to the right settings (direction, screen keyboard, etc)... even if the state changed while the box was sleeping.

divide said...

Oh, I get it now. Well, theoretically the driver could always keep track of it and generate right keys as needed, but it does seem overengineered and silly.

So, I guess your idea is better. Still, you'd want to have some kind of signal or interrupt on that, you wouldn't want krandrtray to go polling the state.

(Yet I'm somehow not fully comfortable with doing that totally on the application level. I can't quite put my finger on why is that, though.)

khnz said...

The basic infrastructure is already there for a while (the input subsystem of linux and the input addon of hal supports it). Userspace programs can simple query hal for the "button with state". If you are interested, I have a hacked patches for krandrtray in my svn (see trunk/patches/krandrtray-*.diff). It's an awful patch, but shows how easy programs can get the state.

Anonymous said...
This comment has been removed by a blog administrator.