On Wed, 2009-04-15 at 10:25 +0200, Bjørn Mork wrote: > Well, you can always argue that the rest can be fixed. Provide patches > etc. But the point is that hal implies a regression for many (most?) > users.
please stop the FUD. > hal breaks existing working configurations without warnings. The simple > test case is using a non-US keyboard properly configured as such in > xorg.conf. Introduce evdev/hal and watch users get frustrated. The > problem of course: keyboard layout cannot be auto-configured. But why > ignore existing configuration? > we don't ignore existing keymap configuration, and you get the same layout after the upgrade as was configured in xorg.conf. > I still haven't got a clue how to really fix this, but have resorted to > this for now: > > <?xml version="1.0" encoding="UTF-8"?> > <deviceinfo version="0.2"> > <device> > <match key="info.capabilities" contains="input.keyboard"> > <merge key="input.xkb.model" type="string">pc105</merge> > <merge key="input.xkb.layout" type="string">no</merge> > </match> > </device> > </deviceinfo> > > IMHO, this is an ugly hack. I never wanted to configure hal. that's fine, you don't have to. > I wanted > to configure X. In fact, I already had a working X configuration so I > didn't expect to configure anything at all... > > Yes, I expected things to "just work", given that it did prior to using > evdev/hal. hal broke that expectation. no, it didn't. you're just spreading nonsense. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
