USB 3G Modem for Vodafone on Slackware

In spite of having to spend too much of my work time getting various 3G dongles working, I’ve never had to do it at home.

For Vodafone, it’s actually quite simple:

1) Install wvstreams
2) Install wvdial
3) Add the following to your /etc/wvdial.conf

[Dialer vodafone]
Init3 = AT+CGDCONT=1,"IP","internet"
Phone = *99#
Password = pass
Username = user

Vodafone don’t actually use a username and password, so you just need something to keep wvdial happy. In my case, I’m then creating a symlink to /dev/modem from /dev/ttyUSB0, but I could just as easily add a ‘Modem = /dev/ttyUSB0’ line as well here.

Connecting is then just a matter of running as root (or using sudo):

wvdial vodafone

Posted on September 4, 2011 at 2:33 pm by Carlos Corbacho · Permalink · Leave a comment
In: Linux, Slackware

Python 2 and Unicode

I’ve been meaning to write this up for a while, so let’s see how we go.

One of the problems I have with Python 2 currently is that Unicode support is a bit of a hit and miss game. The problem is that Unicode was a bolt on extra in Python 2.x – in the brave new world of Python 3, they’ve actually fixed this up properly, with unicode objects being the default, and a new type, bytes, to represent byte strings. Unless you’re doing I/O, then you really do want Unicode (hint – what do you expect len(“£”) to be?) To give an example:

a = "foo"

In Python 2, this will return a str byte string. If you want Unicode objects, you either need an explicit cast:

a = u"foo"

Or, if you’re using Python 2.6:

from __future__ import unicode_literals

a = "foo"

Which is all nice, except libraries are the falling down point, as per usual. The situation on 2.x is basically a mess – not entirely unsurprising, given the origins of the unicode type in Python 2.

Here’s a small selection of the unicode support in Python 2.x libraries:

csv – str only for input and output
ElementTree (and faithfully reproduced in LXML) – Depends. Accepts Unicode, but on return, it tries to coerce everything to ASCII encoded str objects, and if it fails, returns the original internal unicode object.
PyGTK – Accepts unicode, always returns UTF-8 encoded str
PyQt – either QString, or if you switch on the v2 API, unicode objects.
Django – Returns unicode objects
Pyscopg2 – Returns str in the client encoding, unless you specify you want unicode objects (globally or per connection – Django sets this globally)

As for other libraries, I can’t really speak, but I would guess the situation is not much improved there either.

So what are the solutions?

1) Close your eyes, put your fingers in your ears and pretend no-one uses anything but ASCII.

2) Try to only use libraries that actually have proper Unicode support. Oh, and don’t forget to declare every string literal as unicode while you’re there (or use

from __future__ import unicode_literals


3) Use Python 3 (though quite a few libraries still haven’t been ported to it yet, so perhaps not better than 2).

Posted on October 28, 2010 at 9:31 pm by Carlos Corbacho · Permalink · Leave a comment
In: Python

Using a non-US keyboard with X server 1.9

In the brave new world of X server 1.9 (this is with Robby Workman’s latest Xorg packages, but it’s only a matter of time before Slackware picks them up), HAL is dead to X and we now have /etc/X11/xorg.conf.d

However, I still want a UK keyboard layout, and these days, I want my Caps Lock to be another Control key. So I have this – /etc/X11/xorg.conf.d/caps.conf:

Section "InputClass"
Identifier "keyboard-layout"
Driver "evdev"
MatchIsKeyboard "yes"
Option "XkbLayout" "gb"
Option "XkbOptions" "terminate:ctrl_alt_bksp,ctrl:nocaps"
Option "XkbVariant" "basic"

The above now matches all keyboards, and applies the following rules to them (along with anything else you might have, or that is already applied):

1) Apply a UK keyboard layout
2) Give me back Control-Alt-Backspace to restart the X server
3) Make my Caps Lock key another Control key

Posted on October 10, 2010 at 9:42 pm by Carlos Corbacho · Permalink · Leave a comment
In: Linux

Slackware -current & Radeon KMS

It works.

Suspend to RAM appears to be broken (but I haven’t tested that in ages, so might have been broken anyway), but other than that, I’m now running with a custom kernel with KMS enabled on my old Aspire 5021 (Radeon Mobility X700), and it appears to be ok (it can be a bit flaky the first time you enable it – a few cold boots cured that one).

Posted on May 2, 2010 at 7:03 pm by Carlos Corbacho · Permalink · Leave a comment
In: Uncategorized

KDE & Exchange support

I’ve been spending the last few weeks, on and off, trying to figure out the level of Microsoft Exchange support in KDE at the present moment and near future. From lots of digging around various sites, and poking at the source code, it seems that:

1) libmapi (from OpenChange) provides a library that can talk to MS Exchange 2007

2) KDE has an OpenChange resource for Akonadi

3) The Akonadi OpenChange resource is currently not built by default, and based on comments in the make files, not clear what the current status is

4) KMail does not currently use Akonadi anyway, and won’t be ported over to it until at least KDE SC 4.5

Corrections welcome.

Posted on January 19, 2010 at 9:25 pm by Carlos Corbacho · Permalink · Leave a comment
In: KDE, Linux

Using a non-US keyboard in X with Slackware -current (13.0) without xorg.conf

xorg.conf is dead – long live xorg.conf

For a UK layout keyboard, stick the following in /etc/hal/fdi/policy/10-keymap.fdi (for other layouts, change gb and/ or add as appropriate).

This is just enough to merge with the existing file & blat the keyboard layout (without having to resort to re-implementing the default Slackware FDI).

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
    <match key="info.capabilities" contains="input.keys">
      <merge key="input.xkb.layout" type="string">gb</merge>
Posted on June 10, 2009 at 11:05 pm by Carlos Corbacho · Permalink · Leave a comment
In: Linux

tc1100 & rfkill

tc1100 – The other WMI driver I maintain (the one that I’ve never even had the hardware for, let alone set eyes on, which always makes it ‘interesting’ to work on).

I’ve posted patches to add rfkill support to this driver to the linux-acpi mailing list. If you:

1) Have the hardware
2) Can compile your own kernel

Then please grab the patches, try them out and let me know if they work, or break horribly.

Posted on October 10, 2008 at 7:05 pm by Carlos Corbacho · Permalink · Leave a comment
In: Linux, wmi

rfkill update

It’s been a while, so:

1) I’ve posted the final version of the patches to add rfkill support to acer-wmi on the 15th September to the ACPI mailing list.

_Hopefully_ these will go in for 2.6.28.

(This is only for wireless and bluetooth – still waiting for someone to use Linux on an Acer laptop that has built in 3G).

2) For now, rfkill is implemented by polling WMI every second to find the current state of the wireless and bluetooth devices. In future (at least, for WMID compatible laptops), it may be possible to switch this over to a WMI event based system, and avoid polling on those machines, but this will require extensive testing (especially on older machines, such as the Aspire 5040). I may get round to reposting my patch for this somewhere so the more adventurous among you can try it out and feed back.

3) From a button perspective, this will depend on how well rfkill-input is working these days (I haven’t tested lately). However, in HAL, all Acer laptops should be using the same basic keymap now, so we don’t need to keep patching for every single (near identical) laptop for KEY_WLAN and KEY_BLUETOOTH.

4) Unrelated aside to Acer Aspire One owners (so that this is documented somewhere) – it’s not supported by acer-wmi. It only provides a ‘dummy’ interface – the methods in the interface itself don’t actually do anything.

I may explicitly blacklist it in future so that people are aware of this.

Posted on September 29, 2008 at 9:31 pm by Carlos Corbacho · Permalink · 3 Comments
In: acer-wmi, Linux, wmi

acer-wmi & rfkill

I’ve been experimenting now for the last few months with adding rfkill support to acer-wmi in my (rather limited these days) free time (the short, short version of ‘why’ is that this will allow the wireless & bluetooth buttons to just work out of the box on those laptops which have them properly mapped by HAL[1]).

Unfortunately, I’ve been hitting a few snags, most of which I’ve now been able to identify (but there are no solutions at present to all of them):

1) The mysterious double toggle:

Pressing either the wireless or the bluetooth button would trigger both to change states. I tracked this one down yesterday and the fix is pretty trivial.

2) rfkill-input not working until after being reloaded

rfkill-input won’t attach to an input device that doesn’t have KEY_WLAN. But KEY_WLAN isn’t added until HAL kicks in, which is much later. The ‘workaround’ to this is to build a modular rfkill-input, and then reload it after HAL has called setkeycodes. No proper solution yet for this one…

3) The KEY_WLAN cycle of doom

Unfortunately, some of the rfkill enabled wireless drivers send a KEY_WLAN when they detect that the device state has changed. So the following happens:

1) User presses KEY_WLAN
2) rfkill-input toggles all rfkill registered wireless radios
3) acer-wmi gets this signal, and changes the wireless radio state
4) Wireless driver detects the state change, and then helpfully sends a KEY_WLAN
5) Goto 2

And so on until I unload acer-wmi or the offending wireless driver. Consensus so far seems to be that wireless drivers should not using keypresses for event notification.

[1] I now have commit access to the hal-info repository, so I can get your keymaps added as soon as you send them to me 🙂

Posted on April 13, 2008 at 1:27 pm by Carlos Corbacho · Permalink · Leave a comment
In: acer-wmi, Linux · Tagged with: ,

acer_acpi – Latest news

I’ve been rather quiet lately, so time for the latest news:

1) The input part of acer_acpi (the keyboard quirks) has been accepted by Dmitry Torokhov (the input subsystem maintainer) into his tree. This will be going into 2.6.25 – this means that if you have one of the laptops that requires the old acerhk keyboard quirk to make the extra scancodes work, you won’t need acer_acpi just for this fro 2.6.25 onwards. (This code is not acer_acpi specific, so I’ve never been happy with it just sitting in acer_acpi).

2) No news on any other upstream front I’m afraid – wmi & acer-wmi (the upstream port of acer_acpi) are _still_ waiting to be reviewed by the ACPI maintainer (not that I’m getting a little irritated now after three months…)

3) acer_acpi 0.11 will hopefully be released soon – I’ve not had any word of the device autodetection code breaking horribly. Quite the contrary, reports so far indicate that it’s working quite well, so it’s almost time to inflict^^^^^^release it.

4) There appears to be a bug with OpenSuSE 10.3 and the wmi-acer/ wmi module –

I’m aware of it – but currently have no clue as to why it doesn’t work on OpenSuSE, yet works on the same hardware with other distributions.

Posted on January 29, 2008 at 3:28 pm by Carlos Corbacho · Permalink · 5 Comments
In: acer_acpi, Linux