I’ll keep it short: After being inspired by this blog post I decided it was about time the “Performance MX” got support for setting its DPI value in Linux.
After some USB sniffing and poking at a few registers I was successful. Compile the following code with
“gcc -o performance_mx_dpi performance_mx_dpi.c -lusb-1.0 –std=c99”.
Continue reading Logitech Performance MX in Linux
So you’ve got one of those fancy mice with lots of extra (read “spare”) buttons and no configuration interface at all?
Yes, that’s admittedly something the Linux desktop has been lacking for a long time. The drivers are capable of almost everything, but it seems no one ever bothered to add a sophisticated configuration utility for macros or extra buttons – I mean beyond what e.g. Compiz offers. Gamers (if there are any at all) should even more want something like that.
On my Logitech mouse there’s a thumb button to which I’d really like to bind the overlay mode in Gnome Shell. If you know xbindkeys the solution’s quite obvious, just make it listen to that button in .xbindkeysrc:
"/usr/local/bin/show-gnome-shell-overlay" m:0x0 + b:10 + release
My first guess was to scan D-Bus for anything related to “org.gnome.Shell” because nowadays almost everything seems to use D-Bus for IPC. Nevertheless, I have to admit I was quite surprised seeing the overlay after calling that D-Bus method though. ;)
Here’s that script referenced above:
#/bin/sh
dbus-send --session --type=method_call \
--dest=org.gnome.Shell /org/gnome/Shell \
org.freedesktop.DBus.Properties.Set \
string:org.gnome.Shell \
string:OverviewActive \
variant:boolean:true
It has been discussed controversially before its release and it certainly will be for the next few weeks. To be honest I wouldn’t expect anything else if a very important desktop environment decides to make the radical changes Gnome made for their 3.0 release.
Nevertheless, after a few days of using and liking the Gnome Shell and Gnome 3 there’s still a quite a lot I dislike:
Gnome Shell eats my Windows-key. Yeah, using Super_L is a good idea and finally gives that modifier some meaning. I actually used Super for a lot of stuff like
As I said: Gnome eats Super_L which means that every shortcut using that key doesn’t work any more. Bad bug, really bad bug. Well, I admit that’s a small problem, a bug report, and not really influencing productivity here – I just disabled Super_L for now.
The much more annoying “innovation” is the complete lack of applets. I never cluttered panels with lots of stuff – I use only one panel at the top – but there are three applets I can’t live without:
CPU monitor, weather and, most important, my time tracking Hamster.
I frequently caught myself looking at the temperature to only read my username – seriously, who needs to read his own name in the top panel? Alzheimers? – or the Activities button where the hamster applet and CPU monitor used to be.
They are gone (forever?) and I’ll miss them very much. I’m a sad panda.
As already mentioned in “Xorg and HAL” X-land is in state of “complete” redesign.
Today I read at Phoronix that Intel released their driver update 2.11.0. Curious as I tend to be I had to compile Xorg, Mesa and the driver once again to take a look at what’s going on myself.
Because support for setting properties via udev seems to have gone in favour of the shiny new “conf.d” features, my old post is definitely outdated.
Not that big of a deal though, to configure your touchpad/-stick you now have to create InputClass-Sections in *.conf-files in “/etc/X11/xorg.conf.d/” (99-trackstick.conf in this example).
Section "InputClass" Identifier "dualpointstick" MatchProduct "DualPoint Stick" Option "ButtonMapping" "3 2 1 4 5" Option "EmulateWheel" "true" Option "EmulateWheelButton" "2" Option "EmulateWheelTimeout" "400" Option "YAxisMapping" "4 5" EndSection
By the way: Subsequent rules seem to be overwritten, so copying “/usr/lib/X11/xorg.conf.d/05-evdev.conf” makes sure “normal” input devices use the evdev driver.
Ah, in case you might have wondered: Yes, contrary to mice I use touchpads and tracksticks with my left hand. Which other OS would allow me to configure input devices like that?
I decided to learn Python two days ago. Partly because I wanted a quick solution to a problem (and writing C always takes me so long), but also because I’ve read a lot of positive comments about it.
What I wanted was to get rid of the old gnome-osd stuff and beautify the visual output of some shortcut-scripts I use (more about that later). I found out I needed a script that can display notifications (using Ubuntu’s notify-osd) and provide that functionality for other scripts with D-Bus. Continue reading A notification server in Python
With all that Firefox 3.6 news lately, you might have asked yourself where to get it for your 64 Bit system, because though the nightly builds also include x86_64 (to make sure developers don’t break anything), official releases – like latest 3.6 release – don’t.
Here’s what I do: Continue reading Your own 64-Bit-build of Firefox
I’m following the development of a great time-tracking software since mid 2008. Project Hamster, an applet for Gnome’s panel, has constantly evolved from a nice tool to something I could not do without any more.
It’s easy to use, fast and for someone like me (I always forget to write down start and stop times) it comes with a few handy reminding features.
The new interface they are planning for Gnome 2.30 is cleaner and better arranged than ever before, but I’ll let the screenshots (excuse the German labels) speak for themselves.
A few things have been brewing in Linux-world concerning the replacement of HAL for some time now: Ubuntu’s Lucid Lynx (10.04) for example will ship without it.
Xorg 1.7.4 was uploaded to Debian/unstable three days ago and comes with udev support, which also means that support for configuration of input devices via HAL was dropped (at least for Linux).
So, in case you might wonder how to configure your input devices, here’s an example for my Synaptics touchpad. Similar to HAL, put your .fdi-files into “/etc/udev/rules.d/”.
ACTION!="add|change", GOTO="xorg_synaptics_end"
KERNEL!="event*", GOTO="xorg_synaptics_end"
ENV{ID_INPUT_TOUCHPAD}!="1", GOTO="xorg_synaptics_end"
ENV{x11_options.MinSpeed}="0.50"
ENV{x11_options.MaxSpeed}="1.3"
ENV{x11_options.AccelFactor}="0.025"
LABEL="xorg_synaptics_end"
Although you can get rid of HAL completely, some (Gnome-) packages are still built with HAL support and dependencies. I for example had to rebuild gnome-power-manager and sound-juicer but after that I was able to disable HALs start-script. Another problem you might face is the dependency of bluez (the bluetooth implementation) on HAL.
If you’re interested: Xorg developer about udev-directions