Bug#536287: xserver-xorg-video-intel: X apps break severely with Intel KMS (Kernel Modesetting)
I'm also seeing this with KMS, linux 2.6.30-1-amd64 and -intel 2:2.8.0-1. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#363507: Xft needlessly depends on x-dev
Package: xft Version: 2.1.8.2-7 Severity: normal xft build-depends on x-dev, and libxft-dev depends on x-dev. x-dev is simply a transitional package that depends on x11proto-core-dev, and both the build-depends and libxft-dev runtime depends include libx11-dev, which also depends on x11proto-core-dev. Thus, all occurances of x-dev can be removed from the xft package. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part
Bug#259740: Windows key no longer treated as modifer, just as Super_L
I'm still seeing this bug with XFree86 4.3.0.dfsg.1-6ubuntu11 (synced to SVN trunk @ r1777). Fabio M. Di Nitto told me to follow up as this should have been fixed. I have a normal British "Windows" keyboard with the Windows/Menu keys, configured like this: Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc104" Option "XkbLayout" "gb" EndSection xmodmap says this: $ xmodmap xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Alt_L (0x40), Alt_L (0x7d), Meta_L (0x9c) mod2Num_Lock (0x4d) mod3 mod4Super_L (0x7f), Hyper_L (0x80) mod5Mode_switch (0x5d), ISO_Level3_Shift (0x7c) Not totally understanding the X keyboard model, I'll try and explain what happens. My Metacity is configured to switch workspaces on super-arrows. When I let go of the super/Windows key I'd expect the workspace switching popup to go, but it persists until I press it again, as if it wasn't a modifier key. The magic xmodmap line: xmodmap -e 'clear mod4' -e 'add mod4 = Super_L' fixes this temporarily. My GNOME keyboard settings applet says that "super is mapped to the Windows key" is the default setting. Pressing and releasing the left Windows key in xev produces these: KeyPress event, serial 26, synthetic NO, window 0x301, root 0x8e, subw 0x0, time 1593258, (104,3), root:(108,539), state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: "" KeyRelease event, serial 26, synthetic NO, window 0x301, root 0x8e, subw 0x0, time 1593375, (104,3), root:(108,539), state 0x40, keycode 115 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: "" When I go to the GNOME keybindings applet to configure a super-key combination, when I press the super key it doesn't wait for a key along with the modifier, but stops at "Super_L". If I use Meta it waits for me to hit another key and will display something like "5". Anything else I can do to help debug this? Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Bug#225811: Should depend on exact versions
On Wed, 2004-01-07 at 03:53, Daniel Stone wrote: > On Tue, Jan 06, 2004 at 05:00:33PM -0500, Branden Robinson wrote: > > You can add the following to your apt preferences file > > (/etc/apt/preferences): > > > > Package: * > > Pin: release a=xfree86 > > Pin-Priority: 1002 > > > > Please let me know if this solution satisfies your needs. > > Isn't it 'release a=experimental'? Also, there's this: > for package in $(apt-cache showsrc xfree86 | grep ^Binary | cut -f2- -d: | tr > -d ,); do printf "Package: %s\nPin: release a=experimental\nPin-Priority: > 600\n\n" "$package"; done >> /etc/apt/preferences > > The script comes from David B. Harris. Cheers. :) I'd prefer not to pin all of experimental, so that evil script looks like a better solution. The script is better than the script Jeff Waugh mailed me, which scanned parsed the output of dpkg -l... I suggest that both of these are documented in the x-window-system-core (or wherever is more relevant) package, in an FAQ or README. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Bug#225811: Should depend on exact versions
Package: x-window-system Version: 4.3 Severity: wishlist It would be great if x-window-system-core (etc) depends on exact versions of packages (i.e. xlibs 4.3.0pre1v5), so that: apt-get install x-window-system-core/experimental upgraded all core X packages from experimental. At the moment that command simply upgrades the x-window-system-core package, but not the dependencies. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux eddie 2.4.22-1-k7 #5 Sat Oct 4 14:11:12 EST 2003 i686 Locale: LANG=en_GB, LC_CTYPE=en_GB (ignored: LC_ALL set to en_GB)
