Weblogs for mcortese
# /etc/init.d/gdm start; sleep 10; /etc/init.d/gdm stop
was enough to get myself a useful log to inspect. The issue showed up in two surprisingly innocent lines:
(II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device.You have read correctly: they are classified "(II)", merely informational.
I, like many other users, have done without a conf file for a long time, as Xorg is perfectly able to configure itself without the user's help. Or so I thought...
Apparently, the new Xorg put all the burden of detecting and supporting input devices on HAL's shoulders, unless you specify otherwise in the conf file. HAL is the Hardware Abstraction Level, a subsystem that is supposed to take care of the low-level management of the hardware and just exposes a common interface to the applications that use it.
The new version of Xorg trusts HAL so much that it has the option AllowEmptyInput enabled by default. This means that if HAL, for some reason, does not pass any valid input device over to Xorg, the latter will be happy nonetheless. Hence the (II) non-warnings.
Now, I still have to understand why HAL fails to detect my pretty standard keyboard and mouse, but, at least, I discovered how to make my Xorg work in spite of this.
As I said before, Xorg defaults to blindly rely on HAL, but the old, legacy mouse and keyboard modules still work, if properly configured in the conf file. Setting the option AutoAddDevices to off, prevents HAL from getting in the way. A minimal conf file like the following worked for me.
Section "InputDevice" Identifier "My beloved keyboard" Driver "kbd" Option "CoreKeyboard" EndSection Section "InputDevice" Identifier "My beloved mouse" Driver "mouse" Option "CorePointer" Option "Device" "/dev/input/mice" EndSection Section "ServerFlags" Option "AutoAddDevices" "False" EndSection
Of course, disabling the AutoAddDevices also drops the possibility to hotplug input devices. This is only a workaround while waiting to understand what HAL does not like in my mouse and keyboard.
Now I've just noticed that this question is answered, at last, on the About page and the answered is /'de.bi.ən/
Whether this is short-e, long-e, or what else, remains a mystery for us non English speakers (and is indeed the reason why IPA was defined in the first place).
When you plug it into a Windows machine, it is seen as a disk containing the Windows drivers. After installing those drivers, it is seen as a HSDPA/UMTS/GPRS modem.
Of course, no Linux drivers or instructions are provided. When you plug it into your Linux box, it is seen as an USB storage and that's all. The telecom company's help desk simply said that Linux is not supported.
Of course "not supported" doesn't mean "not possible"! This is how to make it work.
First of all, download usb_modeswitch and put the executable in /sbin (I haven't tried the debianized package).
Create a new udev rule /etc/udev/rules.d/45-onda.rules:
# Udev rules for Onda MT505UP
# When seen as a storage, switch it:
SUBSYSTEM=="usb",SYSFS{idVendor}=="19d2",SYSFS{idProduct}=="2000", \
RUN+="/sbin/usb_modeswitch -c /etc/usb_modeswitch_onda.conf"
# When seen as a modem, use it:
SUBSYSTEM=="usb",SYSFS{idVendor}=="19d2",SYSFS{idProduct}=="0002", \
RUN+="/sbin/modprobe usbserial vendor=0x19d2 product=0x0002 maxSize=4096"
And this is /etc/usb_modeswitch_onda.conf: ######################################################## # ONDA MT505UP (most likely a ZTE model) # # Contributor: Alex Scortegagna DefaultVendor= 0x19d2 DefaultProduct= 0x2000 TargetVendor= 0x19d2 TargetProduct= 0x0002 MessageEndpoint=0x03 MessageContent="55534243123456780000010080000a28000000001c00002000000000000000"
Run
# udevadm monitorto see what's happening and plug the dongle.
- udev recognizes it as a storage device (idProduct=0x2000)
- udev obeys my rule and runs usb_modeswitch
- usb_modeswitch makes the magic and the dongle switches to modem-mode
- udev recognizes it as a modem (idProduct=0x0002)
- udev obeys my rule and runs modprobe to load the usbserial kernel module
- usbserial creates the /dev/ttyUSB* special files (please note that it's /dev/ttyUSB1 the one which works).
Test it with minicom: run
# minicom --setupand select /dev/ttyUSB1 as serial port, then try some AT commands (e.g. ATI) to see if it is working.
Now, next problem: the SIM is locked with PIN, and the modem config strings provided with ppp etc. usually don't handle this situation. The solution is the little-known AT command +CPIN=xxxx to unlock the SIM.
The other AT commands to fill in the ppp configuration (the second line is provider-specific, this works for Alice by TIM):
Q0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 +CGDCONT=1,"ip","ibox.tim.it",,0,0and finally the "number" to call is *99#
The simpler one, gdmlogin, provides just the login window you would expect, featuring customized logo and background colour/image, system menu, and face browser.
The second one, gdmgreeter, additionally supports themes. Selecting a theme in GDM's configuration GUI automatically throws in gdmgreeter.
But for me, trying to achieve the quickest boot ever, the main difference is... 5 seconds! So much is gdmgreeter slower than gdmlogin. And it's more CPU-intensive, too.
I don't know if the extra time must be accounted to the theme or it's just that gdmgreeter itself is heavier than its companion, regardless of the selected theme. The point is: if you don't have a good reason to want a themed login screen (and I don't see any), don't select any theme in GDM: your boot will be faster!
I was struck today by yet another Windows feature. A collegue running XP copied a file from a shared directory to his local disc. Then he heavily modified what he thought his copy. Imagine his surprise when he discovered that the original file had been modified as well!
What had happened?
He failed to realize that what he copied actually was just a link to the real thing. On NTFS if you copy a link, you get a link. If you then act on this link, you are really acting on the real thing.
Too bad, the original file now is lost forever, and the collegue has learned a precious lesson!
Gary Parkinson, editor of BBC's "Wake Up to Money", explains why he had hard time when he tried out a laptop equipped with Linux.
Me too, I experienced similar problems. Not with a laptop, though, but with a car.
Much like Mr. Parkinson, I had modest requirements: I just needed a means of transportation from home to my work place, while allowing me to place hand-free phone calls while in the city traffic.
Mainly moved by patriotic motivations, I went for a Fiat model.
I was quite happy with it, except for a couple things which I found particularly annoying.
To begin with, although the car is equipped with a standard USB port in the dashboard area, I couldn't connect it to my mobile phone, which features a proprietary connector.
Then, the instrument panel is really awful, showing the designer's distaste in every detail, from the shape of the dials to the colour of the backlighting. Therefore, I logically decided to replace the car's whole interiors, from dashboard to seats.
After buying a ton of new hardware from my local spare parts seller, I started the replacement, only to find out that the task was harder than I had imagined. As it turned up, Fiat cars are full of bolts, studs, and screws, the sort of things you see in movies when the hero character, hands covered with oil, is desperately tuning the engine of his Formula Indy dragster to get those few extra horse-power that'll make him win the final race.
That was too much for me, whose driving skills are limited to turning the key on and fiddling with some knobs.
I couldn't get any help from the forums I turned to, either, because their language is oriented at the DIY-type, which — as you might have guessed — I'm not.
I finally managed to have the dirty work done by a tuning garage, and everything went in shape (except the mobile phone, but apparently it is the phone that's not compliant with the set standard).
The bottom line is: Fiat cars are great, but be warned that there are things you may want to do with them that require you take a screwdriver and get your hands dirty.
A big company is distributing this bulletin to all its employees equipped with Windows PCs:
- In order to maintain the reliability and ensure optimum performance of your PC, we will begin reminding you of the importance of "rebooting" your PC.
- Rebooting your PC ensures critical security patches, virus protection updates and application upgrades are installed on your PC.
- You will be reminded to reboot your PC with pop-up message notifications, to ensure that the latest upgrades are installed on your PC.
- The pop-up message notifications will begin in mid-July, 2008 for PCs that have not been rebooted within seven days.
Nothing really new: we already knew that for Windows folks rebooting is the cure to all evils...
I have a couple of those 'Big Questions' I would really like to find the 'Ultimate Answer' to.
One is related to the Completely Fair Scheduler (CFS) that was merged into our beloved kernel not without a great deal of discussion.
Is this innovative scheduler really delivering the higher performance that its author promised? Does it grant a better feeling to a desktop's users? Are a server's requests served in a better way, from a client's perspective?
To put it in simpler words: at the end of the day, is being fair definitely a Good Thing to the final user?
Yesterday I discovered something weird about the GNOME panel's workspace switcher, which I could not find in the official documentation. It is based on the meaning given to those workspaces that the above mentioned applet is supposed to switch.
As you may know, the concept of virtual workspace may refer to two different mechanisms, which can even be present at the same time.
- You can have multiple distinct desktops, all independent from each other. You can view only one desktop at a time. The windows can reside on each one of them, and you can send windows from one desktop to the other.
- The size of every single desktop can be higher than the screen size. In that case you only see a portion of the desktop at a time, and that is called a viewport. If your desktop is 4 times the width of the screen, you have 4 possible viewports. The windows can appear on every viewport, and even across the border between adjacent viewports.
If you use Compiz, for example, you can have both multiple desktops (setting the gconf option number_of_desktops) and multiple viewports (setting the options hsize and vsize), but only viewports can be hosted on the faces of the famous spinning cube.
The GNOME panel has an applet that shows the content of the different workspaces and let you switch from one to another. GNOME documentation uses the term workspace without specifying if it refers to desktops or viewports.
Now, I have discovered this weird rule: if there are more than one desktop, GNOME's term workspace means desktop, but if there is only one desktop, then it immediately means viewport.
I find this undocumented "feature" very counter-intuitive, and indeed it can lead the unaware user to hours of frustration.
To use the embedded wireless card on my Compaq Presario laptop, I resorted to the Windows driver loaded with ndiswrapper.
Everything works flawlessly. The only weird thing is that, the network interface must be up before loading the driver. So I have to run:
# ifconfig wlan0 upthen load the driver, and finally:
# iwconfig wlan0