Ikke's Blog

Category: Desktop

Apr 28
How to fix your ACPI buttons, the hackish way

Some time ago my ACPI-driven laptop keyboard buttons (volume control, music player controls,...) stopped working. I'm using the acpi-support package (although not running a Debian derivate) driven by acpid.
Today I decided I wanted my buttons back, so I started to find out what was going wrong.

The issue: acpi_fakekey checks all /dev/input/eventX devices whether or not it's a keyboard device, and if it finds one, it writes the necessary scancode to this device. Since some recent kernel, /dev/input/event0 is no longer my AT keyboard, but one of these ACPI buttons, so writing scancodes to the device won't work: my X server keyboard driver won't see them.

/proc/bus/input/devices told me I need event4 (or use this command: hal-get-property --udi `hal-find-by-capability --capability input | grep KBD` --key input.device | sed "s:/dev/input/event::g"
). Patching acpi_fakekey.c is pretty trivial:

--- acpi-support-0.94/acpi_fakekey.c.orig       2007-04-28 18:09:37.078953488 +0200
+++ acpi-support-0.94/acpi_fakekey.c    2007-04-28 18:09:49.578470914 +0200
@@ -13,7 +13,7 @@
         char filename[32];
         char key_bitmask[(KEY_MAX + 7) / 8];
-        for (i=0; i<32; i++) {
+        for (i=4; i<32; i++) {
                 snprintf(filename,sizeof(filename), "/dev/input/event%d", i);
                 fd = open(filename, O_RDWR);

Replace the 4 with the correct number on your system.

Now my buttons "work" again. Patching acpi_fakekey so it uses HAL to figure out the correct device to write to might be somewhat more reasonable though :-)

Apr 2
Summer of code

Application deadline for Google's Summer of Code 2007 is already some time behind us. Might be interesting to provide a list of proposals I submitted, maybe some other people might pick up a project ;-)

I submitted 3 of them:
- GNOME: HID handling
Basicly, integration of XInputHotplug in the desktop, including per-device settings, and better Bluetooth mouse/keyboard handling (if possible without any command line magic etc.). Enhancing multimedia key support (especially ACPI-based) was a subproject too.
- Django: Row-level permissions
Title says it all. A pretty important project for the Django community.
- Gaim: Porting the Bonjour protocol module to Avahi, and enhance it's functionality
Bonjour-based IM (iChat) is pretty cool and should be (ab)used more. libhowl isn't so nice though as we got the Avahi guys providing us a completely free, glib-integrated mdns/dns-sd stack.

That's about it... I do hope at least one of them gets selected :-) All projects do deserve some love though, that's for sure.

Anyway, while waiting, I'm going to implement some little gimmick panel applet, more about that one later... Still doubting whether to take the Mono/C# or Python road.

Mar 26
Multi-screen setup

I got the multi-display setup I blogged about working after all.
Some issues though:

  • Desktop items are on the secondary monitor while they *should* (imho) be on the primary one. Top panel is on the primary, nice
  • AWN is displayed in the middle of the secondary monitor, not at the bottom, so it's in front of all fullscreen windows etc. See ticket #182
  • The virtual display size is (2*1280)x1024, whilst the primary monitor is only 768px high. Result: things like libnotify notifications in the right bottom corner of the desktop (eg generated by gaim-libnotify) are invisible. New windows are partially in this invisible zone too. Looks like the X stack doesn't handle non-rectangular virtual displays

Beryl runs fine, but I kinda dislike the fact my cube is split over both monitor. Here's what'd really rock, IMHO: instead of having only 4 workspaces, allow me to have 8 workspaces. These are split, 1-4 go on one cube on my primary monitor, 5-8 are on another cube on the secondary display, so I got *2* cubes. It should still be possible to drag windows though: when workspace 2 and 7 are displayed, I should be able to drag a window from one to the other. There might be "overlap" issues here though, ie when the window is not completely on 2, nor completely on 7.
This might fix the different height issue too: workspaces 1-4 are 1280x768, workspaces 5-8 1280x1024. I don't know whether the necessary information can be queried (I guess RandR1.2 will allow this, but my bet is FGLRX won't have RandR1.2 support for over a year).

Last but not least I was thinking it could be pretty cool if composited window managers could handle output cloning. If you got 2 monitors attached to your computer, the WM/CM would see these as one large virtual monitor. It should be able to know about the different monitors though, the boundaries inside the virtual monitor,... If something is displayed then in the part of the virtual monitor (where windows are displayed) this should be copied to the other virtual part, so it's displayed on the secondary monitor too (sounds vague, hard to explain). While doing this, some resolution-bound enhancements could be done on the image to display too (you don't want to run a 4:3 17" TFT at 1280x768, everything looks *strange*), so all monitors can run at their native resolution. This is fairly easy to do using some matrix transformations on the input image, I guess OpenGL also allows this (windows are pixmaps on OpenGL vertices anyway IIRC).

Don't shoot me if some of these ideas are insane or technicly not feasible, this is just a braindump, I'm no X guru.

Anyway, up to writing my Gnome SoC proposal.

*edit* Beryl seems to have a setting to have 2 cubes indeed, but they just rotate their part of one workspace (enable the "3D world display" of windows, you'll see the borders), it's not 2 different workspaces, so when you rotate one cube, the other one rotates too.

Ikke • DesktopPermalink 6 comments
Mar 24
Beryl and Compiz might merge again

Some pretty good news. Let's hope this will allow some more giant leaps on the FOSS Desktop "Bling" (including "useful" bling ;-)) front.

Going to write my SoC application(s) today, also fairly desktop-centered using not-yet-exploited features of our desktop infrastructure. Interesting times! I'll post more information later, mentors welcome ;-)

Mar 23
Dear web, please fix my screens

Old situation = laptop with 1280x768 display + Ati X1600 + fglrx + XGL + Beryl working fine.
New situation = old situation + 1280x1024 TFT connected to laptop VGA out
Desired situation = new situation + working Xinerama-like multihead setup (ie being able to move windows across both monitors, etc) including XGL/Beryl

What I got: after playing with fglrx settings, pairmode line etc, a normal Xorg server with TWM works, windows can be dragged across monitors,...

Whenever I restart GDM (and XGL) though, I can log in, then my standard Beryl-driven GNOME desktop is displayed on my laptop screen, and a second desktop (with its own panel etc) on the external screen. I'm unable though to move my mouse pointer to this screen, can not drag windows,... Basicly, the monitor and the desktop on it can't be used.

This is what I got in my XGL session:
$ fglrxinfo -display :1.0
Xlib: extension "XFree86-DRI" missing on display ":1.0".
Xlib: extension "XFree86-DRI" missing on display ":1.0".
display: :1.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1600
OpenGL version string: 1.2 (2.0.6334 (8.34.8))

display: :1.0 screen: 1
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1600
OpenGL version string: 1.2 (2.0.6334 (8.34.8))

$ xrandr
SZ: Pixels Physical Refresh
*0 1280 x 768 ( 342mm x 203mm ) *60 75 70 72 56 47
Current rotation - normal
Current reflection - none
Rotations possible - normal
Reflections possible - none

$ xdpyinfo | grep dimensions
dimensions: 1280x768 pixels (342x203 millimeters)
dimensions: 1280x1024 pixels (342x271 millimeters)

$ less /etc/X11/xorg.conf
Section "Device"
Identifier "ATI Graphics Adapter1"
Driver "fglrx"
VendorName "ATI Technologies Inc"
BoardName "ATI Radeon Mobility X1600"
Option "OpenGLOverlay" "on"
BusID "PCI:1:0:0"
Option "MonitorLayout" "LVDS, AUTO"
Option "Mode2" "1280x1024"
#Option "ForceMonitors" "LVDS, AUTO"
Option "DesktopSetup" "horizontal,reverse"
#Option "EnablePrivateBackZ" "yes"
Option "PairMode" "1280x768+1280x1024"

It seems like the creation of Xwindows (when opening a menu, or a new application, etc) is very slow too :-( This might be just an impression though.

*update* Enabling Xinerama not by adding it in xorg.conf (doesn't work, enabling Xinerama disables DRI, so Xgl won't work), but by adding "+xinerama" to the Xgl start line in my custom gdm config file, seems to work... somewhat. I get my normal desktop on my laptop monitor, but only the standard grey-like X checkerboard on the external one. I can move my mouse pointer on it though, but get the default X cursor, not my normal one. I can't drag windows to it either, they seem not to get rendered. Maybe I got to recompile some packages to get Xinerama support...
Window creation isn't "slow" anymore too :-)
Strange though:
$ xdpyinfo | grep dimensions
dimensions: 1280x768 pixels (313x181 millimeters)

*update 2* Playing around some more with aticonfig doesn't solve the issue. It's pretty strange: whenever I'm in GDM, all looks fine. Once my GNOME session starts though, the system starts to clone the 1280x768 laptop monitor to the external monitor, which doesn't look very nice (wrong resolution), instead of providing me with a bigger screen, as when GDM is running. Pretty strange!
This is what xrandr says:
$ xrandr
SZ: Pixels Physical Refresh
0 2560 x 1024 ( 684mm x 271mm ) 60
1 1280 x 1024 ( 684mm x 271mm ) 75 70 60
*2 1280 x 768 ( 684mm x 271mm ) *60
3 1024 x 768 ( 684mm x 271mm ) 75 72 70 60
(omitted last lines) Choosing another mode doesn't solve the issue though :(

<< Previous Page :: Next Page >>


Who's Online?

  • Guest Users: 117


XML Feeds

What is RSS?