Bug#381963: serious issues with the touchpad in Latitude D420
On Mon, May 07, 2012 at 11:06:47AM +0200, Cyril Brulebois wrote: > Any chance we could get a status update? We currently have 1.6.0 in > unstable, with X server 1.12. > > If you still can't test anything, I guess we should just close this bug > report? I've downgraded to squeeze because GNOME 3 drove me nuts, so I'm unable to test in unstable. (It's broken in squeeze.) Anyway, the laptop model is no longer sold, and I'm fine with not tapping, so you can probably close. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120507170123.ga25...@uio.no
Bug#279252: [uxterm] uxterm should not override my locale
Package: xterm Version: 4.3.0.dfsg.1-8 Severity: important After discussing this with Branden on IRC, I was asked to file a bug report, so here goes: uxterm is now the default alternative for x-terminal-emulator; however, debian-installer does not set an UTF-8 locale for my language (nb_NO). Thus, I'd expect uxterm to behave like Branden thought it did; quote Branden on IRC: "uxterm doesn't start a UTF-8 xterm if no UTF-8 locale is set". However, uxterm does. If no UTF-8 locale is set (in LC_ALL, LC_CTYPE or LANG), uxterm forcibly adds .UTF-8 to one of those ands starts an xterm with -u8. From my point of view, this is broken; I am using a non-UTF-8 locale (and don't even have any UTF-8 locales generated), yet x-terminal-emulator (which is the default in almost all window managers in Debian) starts up using UTF-8. This means that my xterms suddenly use a different character set from my aterms or eterms or whatnot, and even more important, they use a different character set from my ssh sessions and Linux consoles. I understand that people want to push UTF-8, but a forced default of using UTF-8 does _not_ belong in xterm. If we want UTF-8 to be the default in Debian across the board, that should be set in the installer, so it's globally in place instead of doing ugly shell script wrappers. :-) My proposed solution is to do one or more of the following (in no particular order): 1. Make xterm the default x-terminal-emulator again. 2. Make uxterm not mess with the locale if it isn't UTF-8. 3. Make debian-installer set UTF-8 locales by default for _all_ languages. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8.1 Locale: LANG=C, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1) Versions of packages xterm depends on: ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an ii libexpat1 1.95.8-1 XML parsing C library - runtime li ii libfontconfig12.2.3-3generic font configuration library ii libfreetype6 2.1.7-2.2 FreeType 2 font engine, shared lib ii libice6 4.3.0.dfsg.1-8 Inter-Client Exchange library ii libncurses5 5.4-4 Shared libraries for terminal hand ii libsm64.3.0.dfsg.1-8 X Window System Session Management ii libxaw7 4.3.0.dfsg.1-8 X Athena widget set library ii libxext6 4.3.0.dfsg.1-8 X Window System miscellaneous exte ii libxft2 2.1.2-6FreeType-based font drawing librar ii libxmu6 4.3.0.dfsg.1-8 X Window System miscellaneous util ii libxpm4 4.3.0.dfsg.1-8 X pixmap library ii libxrender1 0.8.3-7X Rendering Extension client libra ii libxt64.3.0.dfsg.1-8 X Toolkit Intrinsics ii xlibs 4.3.0.dfsg.1-8 X Window System client libraries m ii xlibs-data4.3.0.dfsg.1-8 X Window System client data -- no debconf information
Bug#279252: #279252 uxterm should not override my locale
On Tue, Nov 30, 2004 at 08:47:52PM -0500, Thomas Dickey wrote: > xterm patch #197 addresses this by using the error status from the 'locale' > program to check if a given locale is installed. That does not really solve the problem if I should happen to have the UTF-8 locales installed; the default x-terminal-emulator still uses a locale I never asked for (and do not want), which is distinctly different from all other applications (say, Mozilla, or gvim) and the Linux console. /* Steinar */ -- Homepage: http://www.sesse.net/
Bug#279252: #279252 uxterm should not override my locale
retitle 279252 default x-terminal-emulator should not override my locale thanks On Wed, Dec 01, 2004 at 05:54:00AM -0500, Thomas Dickey wrote: >> That does not really solve the problem if I should happen to have the UTF-8 >> locales installed; the default x-terminal-emulator still uses a locale I >> never asked for (and do not want), which is distinctly different from all >> other applications (say, Mozilla, or gvim) and the Linux console. > uxterm sets a UTF-8 locale. > If you don't want a UTF-8 locale, you should not run uxterm. I do not run uxterm. I run x-terminal-emulator, which is supposed to give me a sane terminal emulator by default, but in current sarge, uxterm is the default for x-terminal-emulator. This is what my bug is all about; uxterm should not be the default for x-terminal-emulator. (I've retitled the bug to make it clearer.) /* Steinar */ -- Homepage: http://www.sesse.net/
Bug#279252: #279252 uxterm should not override my locale
On Wed, Dec 01, 2004 at 06:04:20AM -0500, Thomas Dickey wrote: >> I do not run uxterm. I run x-terminal-emulator, which is supposed to give >> me a sane terminal emulator by default, but in current sarge, uxterm is >> the default for x-terminal-emulator. This is what my bug is all about; >> uxterm should not be the default for x-terminal-emulator. (I've retitled >> the bug to make it clearer.) > In that case, it's not a bug against xterm, but against whatever > meta-package owns "x-terminal-emulator". >From xterms postinst: update-alternatives --install /usr/bin/x-terminal-emulator x-terminal-emulator /usr/X11R6/bin/xterm 20 (...) update-alternatives --install /usr/bin/x-terminal-emulator x-terminal-emulator /usr/X11R6/bin/uxterm 30 (...) I don't see how anything but xterm is supposed to change this situation. AFAIK no package "owns" an alternative per se, but I might be wrong here; my understanding of this was that by default, whatever alternative has the highest priority is selected as the alternative in use. /* Steinar */ -- Homepage: http://www.sesse.net/
Bug#279252: #279252 uxterm should not override my locale
On Wed, Dec 01, 2004 at 07:09:42AM -0500, Thomas Dickey wrote: >> I don't see how anything but xterm is supposed to change this situation. >> AFAIK no package "owns" an alternative per se, but I might be wrong here; >> my understanding of this was that by default, whatever alternative has the >> highest priority is selected as the alternative in use. > I would regard that as a defect in the alternatives scheme, since package > maintainers can otherwise choose to set arbitrary priorities for their > favorite packages (and doing so late in the release cycle leads to > competitive issues). You could of course view that as a problem, but it's completely irrelevant here, as xterm's postinst sets the priority for both xterm and uxterm, and it's the relative priorities of those two I want to swap. /* Steinar */ -- Homepage: http://www.sesse.net/
Bug#279252: [uxterm] uxterm should not override my locale
On Thu, Dec 09, 2004 at 04:48:34PM -0500, Branden Robinson wrote: >> I disagree, it has always been pretty clear to me that uxterm is a nice >> way to temporarily switch to a UTF-8 locale, its behavior should not be >> altered. Maybe a new wrapper could be added, say lxterm, to launch >> uxterm in UTF-8 locales and xterm otherwise? > > Not just that, but people have requested a wrapper similar to uxterm called > "koi8rxterm". > > lxterm could decide whether to launch regular xterm, uxterm, or koi8rxterm > based on the character set currently used by the locale. > > What do you guys think? I'd be happy to repurpose this bug for this goal, > and to write the script as well. I do not know enough about xterm to know why it doesn't already launch in UTF-8 mode if the user is in an UTF-8-locale (ie. without a helper script), but apart from that, this sounds excellent to me, as it would make the default x-terminal-emulator respect whatever locale the user has set, which I think is the only sane option in the first place. :-) /* Steinar */ -- Homepage: http://www.sesse.net/
Bug#318015: xserver-xorg: dies in preinst due to debconf bug
Package: xserver-xorg Version: 6.8.2.dfsg.1-1 Severity: serious After first doing "aptitude install xserver-common" and then "aptitude install xserver-xorg" (just "aptitude dist-upgrade" wanted to remove ~300 packages, including GNOME :-) ), I got: xserver-xorg config warning: migrating xserver-xfree86 templates to xserver-xorg. Can't call method "choices" on an undefined value at /usr/share/perl5/Debconf/Question.pm line 85, line 118. Received signal. Aborting xserver-xorg package config script. Then, it installed some other packages, and tried again, giving essentially the same error: xserver-xorg config warning: migrating xserver-xfree86 templates to xserver-xorg. Can't call method "choices" on an undefined value at /usr/share/perl5/Debconf/Question.pm line 85, line 115. Some manual debugging with DEBCONF_DEBUG=developer revealed: [...] debconf (developer): <-- SET xserver-xorg/autodetect_monitor true debconf (developer): --> 0 value set debconf (developer): <-- FSET xserver-xorg/autodetect_monitor seen true debconf (developer): --> 0 true debconf (developer): <-- METAGET xserver-xfree86/config/display/modes choices Can't call method "choices" on an undefined value at /usr/share/perl5/Debconf/Question.pm line 85, line 115. Now, this does indeed exist in debconf: Name: xserver-xfree86/config/display/modes Template: xserver-xfree86/config/display/modes Value: 800x600, 640x480 Owners: xserver-xfree86 However, there are no choices there, actually... and I can't find anything in the templates, either. I guess the problem is: baby:~/xorg> grep -c config/display/modes /var/cache/debconf/templates.dat 0 So, the template in question is kind of half-there, since it has a _value_ but not a template. Now, debconf shouldn't _die_ on this, and that is probably a bug (I guess I'll kick Joey when I see him later today :-) ), for in the meantime this breaks X.org installation in these cases... -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-3-686 Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) -- no debconf information -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#755921: closed by Julien Cristau (Bug#755921: fixed in mesa 10.3.0~rc3-3)
reopen 755921 found 755921 10.6.5-1 thanks On Mon, Sep 15, 2014 at 09:24:22PM +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the libgl1-mesa-dri-dbg package: > > #755921: libgl1-mesa-dri-dbg: debug version of i965_dri.so missing It seems this is back: libgl1-mesa-dri-dbg contains no i965_dri.so in current unstable. /* Steinar */ -- Homepage: http://www.sesse.net/
Bug#755921: closed by Julien Cristau (Bug#755921: fixed in mesa 10.3.0~rc3-3)
On Wed, Sep 09, 2015 at 07:34:00PM +0200, Sven Joachim wrote: >> It seems this is back: libgl1-mesa-dri-dbg contains no i965_dri.so >> in current unstable. > Of course not, because the packaging was switched to debhelper 9 in mesa > 10.3.0~rc3-3. ...OK? Perhaps some context would be in order, because I don't know why debhelper 9 would break things. > Does gdb not pick up the symbols under /usr/lib/debug/.build-id > automatically? perf doesn't. I don't know about gdb. /* Steinar */ -- Homepage: http://www.sesse.net/
Bug#755921: closed by Julien Cristau (Bug#755921: fixed in mesa 10.3.0~rc3-3)
On Wed, Sep 09, 2015 at 08:26:30PM +0200, Sven Joachim wrote: >> perf doesn't. I don't know about gdb. > Looks like you have been hit by bug #661193[3]. Two days ago somebody sent > a patch the LKML[4], apparently without any reply yet. OK; so seemingly perf is supposed to look into /usr/lib/debug/.build-id and find the files there (with no filename ending in .so), but doesn't? I'll just need to wait until it gets fixed, then. Thanks for the information. /* Steinar */ -- Homepage: http://www.sesse.net/
Bug#806805: debian/copyright contains wrong license (copyright assignment no longer needed)
Source: mesa Version: 11.0.6-1 Severity: normal Hi, debian/copyright in Mesa contains the following language: When contributing to the Mesa project you must agree to relinquish your work to the holder of the copyright for the particular component you're contributing to. That is, you can't put your own copyright on the code, unless it's a modular piece that can be omitted from Mesa (like a new device driver). If for example, you contribute a bug fix to Mesa's texture mapping code, your code will become a part of the body of work which is copyrighted by Brian Paul and licensed by the above terms. However, this language no longer exists upstream; it was removed in b7c727e5006e26be3f70396030aab7512498f441 (August 2005!) and replaced by When contributing to the Mesa project you must agree to the licensing terms of the component to which you're contributing. The following section lists the primary comonents of the Mesa distribution and their respective licenses. It recently caused me some headache, so it would be nice to see it updated with the correct copy. -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (750, 'stable'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0 (SMP w/40 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#364012: This bug is pending...
On Fri, May 05, 2006 at 01:13:39AM +0200, David Martínez Moreno wrote: > tags 364012 + pending > thanks for the fish This was two months ago. Any progress? :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370149: Ping
Hi, Any progress on getting libxfont 1.2.0 into unstable? I guess NMUing with a new upstream version would be slightly risky for anyone not knowing much about X internals :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381882: please add latitude to $inetkbds
Package: xkb-data Version: 0.8-6 Severity: normal Please add latitude to the list of $inetkbds in /usr/share/X11/xkb/rules/base -- I have a Dell Latitude, and it definitely has keys that need the "+inet" mapping to work properly. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381884: [xkbcomp] searches in obsolete directory /etc/X11/xkb
Package: xbase-clients Version: 1:7.1.ds-2.1 Severity: important xkbcomp is currently completely broken unless you happen to run it from /usr/share/X11/xkb: fugl:~> setxkbmap -print | xkbcomp - $DISPLAY Error:Can't find file "xfree86" for keycodes include Exiting Abandoning keycodes file "(null)" strace shows that it's searching in /etc/X11/xkb, which disappeared a while ago (at least it isn't anywhere on my system). I haven't been able to figure out _why_, though; I'm not really into the build system and what is supposed to link to what... -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) Versions of packages xbase-clients depends on: ii libc6 2.3.6-18 GNU C Library: Shared libraries ii libfontconfig1 2.3.2-7 generic font configuration library ii libfreetype62.2.1-2 FreeType 2 font engine, shared lib ii libfs6 2:1.0.0-3X11 Font Services library ii libgl1-mesa-glx [li 6.5.0.cvs.20060524-1 A free implementation of the OpenG ii libice6 1:1.0.0-3X11 Inter-Client Exchange library ii libpng12-0 1.2.8rel-5.2 PNG library - runtime ii libsm6 1:1.0.0-4X11 Session Management library ii libx11-62:1.0.0-7X11 client-side library ii libxau6 1:1.0.0-3X11 authorisation library ii libxaw7 1:1.0.1-5X11 Athena Widget library ii libxcursor1 1.1.5.2-5X cursor management library ii libxext61:1.0.0-4X11 miscellaneous extension librar ii libxft2 2.1.8.2-8FreeType-based font drawing librar ii libxi6 1:1.0.0-5X11 Input extension library ii libxkbfile1 1:1.0.2-3X11 keyboard file manipulation lib ii libxmu6 1:1.0.1-3X11 miscellaneous utility library ii libxmuu11:1.0.1-3X11 miscellaneous micro-utility li ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender1 1:0.9.0.2-4 X Rendering Extension client libra ii libxss1 1:1.0.1-4X11 Screen Saver extension library ii libxt6 1:1.0.0-5X11 toolkit intrinsics library ii libxtrap6 1:1.0.0-4X11 event trapping extension libra ii libxtst61:1.0.1-5X11 Testing -- Resource extension ii libxv1 1:1.0.1-5X11 Video extension library ii libxxf86dga12:1.0.0-3X11 Direct Graphics Access extensi ii libxxf86vm1 1:1.0.0-4X11 XFree86 video mode extension l ii x11-common 1:7.0.22 X Window System (X.Org) infrastruc ii zlib1g 1:1.2.3-13 compression library - runtime xbase-clients recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381950: doesn't know debian-installer/keymap = no-latin1 => xkblayout = "no"
Package: xserver-xorg Version: 1:7.0.22 Severity: normal The xserver-xorg config script attempts to grok debian-installer/keymap and set XkbModel/XkbLayout accordingly. However, it doesn't recognize "no-latin1", only "no", and thus falls back to the default (pc104/us). I don't really think there's an exact mapping for no-latin1 in the Xkb rules, but "no" should at least be ages better than "us". :-) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-sesse Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) Versions of packages xserver-xorg depends on: ii debconf 1.5.3 Debian configuration management sy ii x11-common1:7.0.22 X Window System (X.Org) infrastruc ii xbase-clients 1:7.1.ds-2.1 miscellaneous X clients ii xkb-data 0.8-6 X Keyboard Extension (XKB) configu ii xserver-xorg-core 1:1.0.2-9 X.Org X server -- core server ii xserver-xorg-input-al 1:7.0.22 the X.Org X server -- input driver ii xserver-xorg-input-ev 1:1.1.2-1 X.Org X server -- evdev input driv ii xserver-xorg-input-kb 1:1.0.1.3-2X.Org X server -- keyboard input d ii xserver-xorg-input-mo 1:1.0.4-3 X.Org X server -- mouse input driv ii xserver-xorg-video-al 1:7.0.22 the X.Org X server -- output drive ii xserver-xorg-video-ap 1:1.0.1.5-2X.Org X server -- APM display driv ii xserver-xorg-video-ar 1:0.5.0.5-2X.Org X server -- ark display driv ii xserver-xorg-video-at 1:6.5.8.0-1X.Org X server -- ATI display driv ii xserver-xorg-video-ch 1:1.0.1.3-3X.Org X server -- Chips display dr ii xserver-xorg-video-ci 1:1.0.0.5-2X.Org X server -- Cirrus display d ii xserver-xorg-video-cy 1:1.0.0.5-2X.Org X server -- Cyrix display dr ii xserver-xorg-video-du 1:0.1.0.5-2X.Org X server -- dummy display dr ii xserver-xorg-video-fb 1:0.1.0.5-2X.Org X server -- fbdev display dr ii xserver-xorg-video-gl 1:1.0.1.3-3X.Org X server -- Glint display dr ii xserver-xorg-video-i1 1:1.1.0.5-2X.Org X server -- i128 display dri ii xserver-xorg-video-i7 1:1.0.0.5-2X.Org X server -- i740 display dri ii xserver-xorg-video-i8 1:1.5.1.0-2X.Org X server -- Intel i8xx, i9xx ii xserver-xorg-video-im 1:1.0.0.5-2X.Org X server -- IMSTT display dr ii xserver-xorg-video-mg 1:1.2.1.3.dfsg.1-2 X.Org X server -- MGA display driv ii xserver-xorg-video-ne 1:1.0.0.5-2X.Org X server -- Neomagic display ii xserver-xorg-video-ne 1:0.1.4.1-3X.Org X server -- Newport display ii xserver-xorg-video-ns 1:2.7.6.5-2X.Org X server -- NSC display driv ii xserver-xorg-video-nv 1:1.0.1.5-2X.Org X server -- NV display drive ii xserver-xorg-video-re 1:4.0.1.3.dfsg.1-2 X.Org X server -- Rendition displa ii xserver-xorg-video-s3 1:1.8.6.5-2X.Org X server -- S3 ViRGE display ii xserver-xorg-video-sa 1:2.0.2.3-4X.Org X server -- Savage display d ii xserver-xorg-video-si 1:1.3.1.5-3X.Org X server -- SiliconMotion di ii xserver-xorg-video-si 1:0.8.1.3-2X.Org X server -- SiS display driv ii xserver-xorg-video-si 1:0.7.1.3-2X.Org X server -- SiS USB display ii xserver-xorg-video-td 1:1.1.1.3-3X.Org X server -- tdfx display dri ii xserver-xorg-video-tg 1:1.0.0.5-3X.Org X server -- TGA display driv ii xserver-xorg-video-tr 1:1.0.1.2-2X.Org X server -- Trident display ii xserver-xorg-video-ts 1:1.0.0.5-2X.Org X server -- Tseng display dr ii xserver-xorg-video-v4 0.0.1.5-1 X.Org X server -- Video 4 Linux di ii xserver-xorg-video-ve 1:1.0.1.3-2X.Org X server -- VESA display dri ii xserver-xorg-video-vg 1:4.0.0.5-2X.Org X server -- VGA display driv ii xserver-xorg-video-vi 1:0.1.33.2-3 X.Org X server -- VIA display driv ii xserver-xorg-video-vm 1:10.11.1.3-2 X.Org X server -- VMware display d ii xserver-xorg-video-vo 1:1.0.0.5-2X.Org X server -- Voodoo display d Versions of packages xserver-xorg recommends: ii discover1 1.7.18hardware identification system ii laptop-detect 0.12.1attempt to detect a laptop pn mdetect(no description available) ii xresprobe 0.4.23debian1 X Resolution Probe -- debconf information: xserver-xorg/multiple_possible_x-drivers: xserver-xorg/config/monitor/use_sync_ranges: xserver-xorg/config/inputdevice/mouse/port: /dev/input/mice xserver-xorg/config/doublequote_in_string_error: xserver-xorg/config/monitor/screen-size: 17 inches (430 mm) shared/default-x-server: xserver-xorg xserver-xorg/autodetect_monitor: true xserver-xorg/config/input
Bug#381952: please autodetect Dell Latitude keyboards
Package: xserver-xorg
Version: 1:7.0.22
Severity: wishlist
Dell Latitudes have a specific XKB model ("latitude") which is useful
for detecting certain extra keys, such as the volume keys. However, this
is not autodetected by the xserver-xorg configuration script, so the
user has to enable that model manually.
Autodetecting a Latitude is not difficult, but rather hairy -- it's
basically a matter of
dmidecode --string system-product-name | grep -q '^Latitude ' && LATITUDE=yes
If you want to feel extra paranoid, you can also check that "dmidecode
--string system-manufacturer" matches "Dell Inc.", but I can't guarantee
that all Latitudes will have that.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-sesse
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8)
Versions of packages xserver-xorg depends on:
ii debconf 1.5.3 Debian configuration management sy
ii x11-common1:7.0.22 X Window System (X.Org) infrastruc
ii xbase-clients 1:7.1.ds-2.1 miscellaneous X clients
ii xkb-data 0.8-6 X Keyboard Extension (XKB) configu
ii xserver-xorg-core 1:1.0.2-9 X.Org X server -- core server
ii xserver-xorg-input-al 1:7.0.22 the X.Org X server -- input driver
ii xserver-xorg-input-ev 1:1.1.2-1 X.Org X server -- evdev input driv
ii xserver-xorg-input-kb 1:1.0.1.3-2X.Org X server -- keyboard input d
ii xserver-xorg-input-mo 1:1.0.4-3 X.Org X server -- mouse input driv
ii xserver-xorg-video-al 1:7.0.22 the X.Org X server -- output drive
ii xserver-xorg-video-ap 1:1.0.1.5-2X.Org X server -- APM display driv
ii xserver-xorg-video-ar 1:0.5.0.5-2X.Org X server -- ark display driv
ii xserver-xorg-video-at 1:6.5.8.0-1X.Org X server -- ATI display driv
ii xserver-xorg-video-ch 1:1.0.1.3-3X.Org X server -- Chips display dr
ii xserver-xorg-video-ci 1:1.0.0.5-2X.Org X server -- Cirrus display d
ii xserver-xorg-video-cy 1:1.0.0.5-2X.Org X server -- Cyrix display dr
ii xserver-xorg-video-du 1:0.1.0.5-2X.Org X server -- dummy display dr
ii xserver-xorg-video-fb 1:0.1.0.5-2X.Org X server -- fbdev display dr
ii xserver-xorg-video-gl 1:1.0.1.3-3X.Org X server -- Glint display dr
ii xserver-xorg-video-i1 1:1.1.0.5-2X.Org X server -- i128 display dri
ii xserver-xorg-video-i7 1:1.0.0.5-2X.Org X server -- i740 display dri
ii xserver-xorg-video-i8 1:1.5.1.0-2X.Org X server -- Intel i8xx, i9xx
ii xserver-xorg-video-im 1:1.0.0.5-2X.Org X server -- IMSTT display dr
ii xserver-xorg-video-mg 1:1.2.1.3.dfsg.1-2 X.Org X server -- MGA display driv
ii xserver-xorg-video-ne 1:1.0.0.5-2X.Org X server -- Neomagic display
ii xserver-xorg-video-ne 1:0.1.4.1-3X.Org X server -- Newport display
ii xserver-xorg-video-ns 1:2.7.6.5-2X.Org X server -- NSC display driv
ii xserver-xorg-video-nv 1:1.0.1.5-2X.Org X server -- NV display drive
ii xserver-xorg-video-re 1:4.0.1.3.dfsg.1-2 X.Org X server -- Rendition displa
ii xserver-xorg-video-s3 1:1.8.6.5-2X.Org X server -- S3 ViRGE display
ii xserver-xorg-video-sa 1:2.0.2.3-4X.Org X server -- Savage display d
ii xserver-xorg-video-si 1:1.3.1.5-3X.Org X server -- SiliconMotion di
ii xserver-xorg-video-si 1:0.8.1.3-2X.Org X server -- SiS display driv
ii xserver-xorg-video-si 1:0.7.1.3-2X.Org X server -- SiS USB display
ii xserver-xorg-video-td 1:1.1.1.3-3X.Org X server -- tdfx display dri
ii xserver-xorg-video-tg 1:1.0.0.5-3X.Org X server -- TGA display driv
ii xserver-xorg-video-tr 1:1.0.1.2-2X.Org X server -- Trident display
ii xserver-xorg-video-ts 1:1.0.0.5-2X.Org X server -- Tseng display dr
ii xserver-xorg-video-v4 0.0.1.5-1 X.Org X server -- Video 4 Linux di
ii xserver-xorg-video-ve 1:1.0.1.3-2X.Org X server -- VESA display dri
ii xserver-xorg-video-vg 1:4.0.0.5-2X.Org X server -- VGA display driv
ii xserver-xorg-video-vi 1:0.1.33.2-3 X.Org X server -- VIA display driv
ii xserver-xorg-video-vm 1:10.11.1.3-2 X.Org X server -- VMware display d
ii xserver-xorg-video-vo 1:1.0.0.5-2X.Org X server -- Voodoo display d
Versions of packages xserver-xorg recommends:
ii discover1 1.7.18hardware identification system
ii laptop-detect 0.12.1attempt to detect a laptop
pn mdetect(no description available)
ii xresprobe 0.4.23debian1 X Resolution Probe
-- debconf information:
xserver-xorg/multiple_possible_x-drivers:
xserver-xorg/config/monitor/use_sync_ranges:
xserver-xorg/config/
Bug#381952: please autodetect Dell Latitude keyboards
tags 381952 + patch thanks On Tue, Aug 08, 2006 at 01:19:32AM +0200, Steinar H. Gunderson wrote: > Autodetecting a Latitude is not difficult, but rather hairy -- it's > basically a matter of > > dmidecode --string system-product-name | grep -q '^Latitude ' && > LATITUDE=yes I've written up a quick patch to do this for various laptops, but it's largely untested yet, and I don't know if dmidecode is available during xorg configuration; I'll have to check that with Joey. /* Steinar */ -- Homepage: http://www.sesse.net/ diff -ur xorg-7.0.22/debian/xserver-xorg.config.in xorg-7.0.22.patched/debian/xserver-xorg.config.in --- xorg-7.0.22/debian/xserver-xorg.config.in 2006-06-12 05:40:21.0 +0200 +++ xorg-7.0.22.patched/debian/xserver-xorg.config.in 2006-08-08 11:50:43.0 +0200 @@ -964,6 +964,99 @@ warn "selected layout '$XMAP' from '$DI_KEYMAP--$REALLANG' is l2-only" fi + # Try to guess the keyboard model if we have a laptop; largely adapted + # from hotkey-setup by Matthew Garrett and laptop-detect by Thom May + + # Are we a Mac? + if [ -d /proc/pmu ]; then +batteries=$(grep Battery /proc/pmu/info| cut -f2 -d:) +if test "$batteries" -ne 0; then + MODEL=apple_laptop +fi + fi + + # Try to get information out of dmidecode, if we can + if [ -x /usr/sbin/dmidecode ]; then +manufacturer=`dmidecode --string system-manufacturer` +name=`dmidecode --string system-product-name` +version=`dmidecode --string system-version` +chassis=`dmidecode --string chassis-type` + +case "$manufacturer" in +Acer*) + case "$name" in + Ferrari*4000*) +MODEL=acer_ferrari4k +;; + TravelMate*800*) +MODEL=acer_acer_tm_800 +;; + esac + ;; + +Dell*) + case "$name" in + Latitude*) +MODEL=latitude +;; + esac + ;; + +Hewlett-Packard*) + case "$name" in + Omnibook*XE3*GC*) +MODEL=hpxe3gc +;; + Omnibook*XE3*GF*) +MODEL=hpxe3gf +;; + Omnibook*XT1000*) +MODEL=hpxt1000 +;; + Omnibook*500*FA*) +MODEL=hp500fa +;; + Omnibook*5*) +MODEL=hp5xx +;; + Omnibook*6000*) +MODEL=hp6000 +;; + Omnibook*6100*) +MODEL=hp6000 +;; + Pavillion*ZT11*) +MODEL=hpzt11xx +;; + esac + ;; + +IBM*) + case "$version" in + *ThinkPad*) +MODEL=thinkpad +;; + esac + ;; + +LENOVO*) + case "$version" in + *ThinkPad*) +MODEL=thinkpad +;; + esac + ;; + +Toshiba*) + case "$name" in + Satellite*S3000*) +MODEL=toshiba_s3000 +;; + esac + ;; +esac + fi + XKBLAYOUT="$XMAP" XKBOPTIONS="$OPTIONS" XKBVARIANT="$VARIANT"
Bug#381952: please autodetect Dell Latitude keyboards
On Tue, Aug 08, 2006 at 07:31:24AM -0500, Christian Perrier wrote: > Well, on my Dell X1, the following *breaks* the support for volume > control keys: This is precisely the kind of data we need to pull in. Two valuable points: 1. I missed the "inspiron" keymap altogether, probably since it didn't start with "Dell". The patch should be updated to search for Inspiron* in addition to Latitude*. 2. There should be an exception for X1. Do you have the dmidecode data handy? I also seem to have missed the "armada" and "presario" keyboards, but I don't know what the dmidecode output for such Compaqs looke like these days. Unfortunately, we need to gather this kind of data and make tables of rules and exceptions -- there are no fast and easy solutions. :-/ /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381952: please autodetect Dell Latitude keyboards
On Tue, Aug 08, 2006 at 02:43:51PM +0200, Steinar H. Gunderson wrote: > 2. There should be an exception for X1. Do you have the dmidecode data > handy? On second thought (as discussed on IRC), you're probably running into #381882 here, so no exception should be needed (just a bugfix). /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383465: Contains obfuscated source code, DFSG violation?
On Thu, Aug 17, 2006 at 02:12:17PM +0100, Matthew Garrett wrote: > The nv driver appears to be heavily obfuscated and is effectively > The idea that nvidia do not posess an electronic list of register names > and offsets is entirely implausible. The only rational explanation is > that register information is postprocessed out in order to reduce > information leakage. Or that nVidia never wrote the driver in the first place. I cannot find any nVidia copyrights on it -- it seems to have been reverse-engineered and then written up by the current copyright holders. > The shipped code is certainly not the preferred form for modification TBH, I don't think there is any other form in existence, unless you want to count the proprietary drivers this probably was reverse engineered from at some distant past. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383465: Contains obfuscated source code, DFSG violation?
On Tue, Aug 29, 2006 at 10:41:17AM +0300, Daniel Stone wrote: >> Or that nVidia never wrote the driver in the first place. I cannot find any >> nVidia copyrights on it -- it seems to have been reverse-engineered and then >> written up by the current copyright holders. > The output of the below has been tidied up a bit to remove duplicates: OK, my analysis was clearly incorrect. With the information you presented, I agree with Matthew. :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390254: missing dependencies
Package: compiz Version: 0.0.13+git20060928-2 Severity: grave fugl:~> compiz --replace gconf [1] + done metacity --replace /usr/bin/compiz.real: symbol lookup error: /usr/bin/compiz.real: undefined symbol: XCompositeGetOverlayWindow I guess some dependency is missing; I didn't do a full dist-upgrade (since my mirror isn't synced yet). FWIW, it took about ten seconds before it actually got to that part, but so did metacity --replace, so I guess that's some sort of unrelated problem local to my machine. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-rc5 Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) Versions of packages compiz depends on: ii compiz-core 0.0.13+git20060928-2 OpenGL window and compositing mana ii compiz-gnome0.0.13+git20060928-2 OpenGL window and compositing mana ii compiz-gtk 0.0.13+git20060928-2 OpenGL window and compositing mana ii compiz-plugins 0.0.13+git20060928-2 OpenGL window and compositing mana compiz recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392757: non-English keys broken
Package: libx11-data
Version: 2:1.0.3-1
Severity: important
After tonight's dist-upgrade, my non-English keys (most notably æ, ø, å) have
stopped working; I seem to get events for them (due to xev), but they won't
show up in any terminals (I get simply no reaction at all). Downgrading
libx11-data to 2:1.0.0-9 and restarting X restores the behaviour back to
normal.
My "setxkbmap -print" (with 2:1.0.0-9) is as follows:
fugl:~> setxkbmap -print
xkb_keymap {
xkb_keycodes { include "xfree86+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat{ include "complete" };
xkb_symbols { include
"pc(pc105)+no+inet(latitude)+level3(ralt_switch_for_alts_toggle)+group(alts_toggle)"
};
xkb_geometry { include "pc(latitude)" };
};
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-rc5
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8)
Versions of packages libx11-data depends on:
ii x11-common1:7.1.0-3 X Window System (X.Org) infrastruc
libx11-data recommends no packages.
-- no debconf information
Bug#392757: non-English keys broken
severity 392757 critical tags 392757 + pending merge 392757 392567 thanks On Thu, Oct 12, 2006 at 01:00:16PM +0200, Steinar H. Gunderson wrote: > After tonight's dist-upgrade, my non-English keys (most notably æ, ø, å) have > stopped working; I seem to get events for them (due to xev), but they won't > show up in any terminals (I get simply no reaction at all). Downgrading > libx11-data to 2:1.0.0-9 and restarting X restores the behaviour back to > normal. Sorry, this one got stuck in my mail queue and only escaped today; obviously a dupe, merging. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#598803: xserver-xorg-video-intel: X crashes / hung gpu, now and then
On Sat, Oct 02, 2010 at 11:26:30AM +0200, Cyril Brulebois wrote: > Is it still possible to start X again without rebooting? I'd guess so, > but let's check. I'm seeing the issue of hung GPU, after which a lot of applications (in particular urxvt) become very messed up. Restarting X does not help for me. [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 3894 at 3893) [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Kernel 2.6.36-rc6. > If you find a particular pattern / way to reproduce this issue, I'd be > glad to hear about it. I can reproduce it 100% reliably by trying to play http://www.youtube.com/watch?v=IrwjatDnLKY in Google Chrome with HTML5 enabled. > It'd be nice to know how it goes with 2.13.0-1 (just uploaded to > experimental, so available in a few hours). I'll give it a shot. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101002114536.ga7...@uio.no
Bug#598803: xserver-xorg-video-intel: X crashes / hung gpu, now and then
On Sat, Oct 02, 2010 at 04:36:20PM +0200, Julien Cristau wrote: > Please grab /sys/kernel/debug/dri/0/i915_error_state when the hang > happens, so we can forward that upstream. During the hang it's a bit difficult to do anything, I think; but right after is good? Or is it good also a few hours after? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101002151223.ga7...@uio.no
Bug#598803: xserver-xorg-video-intel: X crashes / hung gpu, now and then
On Sat, Oct 02, 2010 at 06:07:51PM +0200, Cesare Leonardi wrote: > Hello Steinar, can you tell us what's your chipset? 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) It's a Dell Latitude D420, FWIW. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101002163114.gb7...@uio.no
Bug#598803: xserver-xorg-video-intel: X crashes / hung gpu, now and then
On Sat, Oct 02, 2010 at 07:07:31PM +0200, Sven Joachim wrote: >> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, >> 943/940GML Express Integrated Graphics Controller (rev 03) > I have the same one, and the HTML5 Youtube video you mentioned works > fine in Chromium with Kernel 2.6.36-rc6, libdrm 2.4.22 and > xserver-xorg-video-intel 2.13.0. Upgrading to 2.13.0 makes it work just fine for me. I also realize I selected a fantastic YouTube video to experiment with :-D To my defense, I hadn't actually seen it myself (after all, my GPU was hanging every time I tried). /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2010100424.gi7...@uio.no
Bug#598803: xserver-xorg-video-intel: X crashes / hung gpu, now and then
On Sun, Oct 03, 2010 at 12:24:24AM +0200, Steinar H. Gunderson wrote: > Upgrading to 2.13.0 makes it work just fine for me. ...at least until I tried to watch http://www.youtube.com/watch?v=INqbAWnbstI in Chrome with HTML5 enabled. That killed all of X, and when starting up again the exact same urxvt rendering issues were back. :-/ /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101005235103.ga25...@uio.no
Bug#598803: xserver-xorg-video-intel: X crashes / hung gpu, now and then
found 598803 2:2.13.0-2 found 598803 2:2.13.901-2 thanks On Wed, Oct 06, 2010 at 01:51:03AM +0200, Steinar H. Gunderson wrote: > ...at least until I tried to watch http://www.youtube.com/watch?v=INqbAWnbstI > in Chrome with HTML5 enabled. That killed all of X, and when starting up > again the exact same urxvt rendering issues were back. :-/ I would just add that I'm still seeing this, also with the version from experimental, and with kernel 2.6.37-rc1. Every time I visit any page with HTML5 video (any YouTube page, any Vimeo page) in Chrome, my GPU hangs and I have to reboot to get proper graphics back. Every other player works fine, though, including the very same pages via Flash. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101120195751.ga12...@uio.no
Bug#381963: serious issues with the touchpad in Latitude D420
On Wed, Jan 19, 2011 at 12:20:07AM +0100, Cyril Brulebois wrote: > how are things going with the X stack from squeeze/sid, or the one > from experimental? It'd be nice to report any issues upstream anwyay: > http://bugs.freedesktop.org/ > > (with component: xorg, product: Input/synaptics.) There's been no difference during the entire lifetime of my laptop. I've basically just learned not to tap. I'm abroad right now so I don't really have time to follow up this kind of bugs, though :-/ /* Steinra */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110118233501.gc10...@uio.no
Bug#403818: xserver-xorg: no video or keyboard after upgrading to sarge (deps too loose)
Package: xserver-xorg Version: 1:7.1.0-8 Severity: serious Justification: 23:28 < vorlon> Sesse: I'd call it RC, no? After dist-upgrading (using etch's aptitude) from sarge to etch, one machine here was completely without keyboard or mouse support, and X refused to work. A bit of hunting revealed that aptitude had pulled in xserver-xorg-input-magictouch and xserver-xorg-video-siliconmotion to fulfill xserver-xorg's dependencies on "xserver-xorg-video-all | xserver-xorg-video" and "xserver-xorg-input-all | xserver-xorg-input", respectively. This is clearly not satisfiable. AFAICS there are two OK ways of solving this: 1. Make the depends into "xserver-xorg-video, xserver-xorg-input", and add Recommends for the -all packages instead. 2. Add xserver-xorg-input-kbd and xserver-xorg-input-mouse explicitly to the list of depends (or possibly recommends?), which should make aptitude Do The Right Thing (hopefully). This won't solve the issue for video, though. One could use a combination of 1 and 2. Note that the request to "aptitude install xorg", which was given by debconf, was a no-op, since all the dependencies were already fulfilled. Also, xorg.conf was blank after the upgrade, but I guess that's for another bug, which will be far harder to track down... :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403818: xserver-xorg: no video or keyboard after upgrading to sarge (deps too loose)
On Tue, Dec 19, 2006 at 08:40:26PM -0500, David Nusinow wrote: > Ouch. This is a bug in aptitude, aiui. It should be choosing the first > option if nothing is currently installed, and allowing the second to > substitute. Probably something in -all caused a conflict, and the conflict resolution manager preferred a random choice providing -input instead. > Either way, it's probably too late to fix this in aptitude for etch, so a > workaround is necessary... Most upgrades will probably happen with the aptitude from sarge, BTW. >> 1. Make the depends into "xserver-xorg-video, xserver-xorg-input", and >> add Recommends for the -all packages instead. > If I build a package set with this, will you be able to test it to make > sure it works? Unfortunately, no; the machine was just my mother's workstation. However, I've picked out the dpkg status backup and reconstructed the aptitude lines; talk to Julien Cristau, he has the data in question. >> Also, xorg.conf was blank after the upgrade, but I guess that's for >> another bug, which will be far harder to track down... :-) > Gyah... did xserver-xorg error out during postinst? I'll have to look for a > codepath that can cause that beyond errors. No, it didn't error out. It just showed the warning debconf template, and then continued as nothing was wrong. Note that due to some conflicts etc., the upgrading line was "aptitude install gnome" (the full dist-upgrade was not done until later); it _might_ be that a full dist-upgrade is luckier somehow, but I'm not going to bet on it. Just giving aptitude the explicit hint that the user would probably like to have -input-(kbd,mouse) and -video-vesa sounds like the best hint to me, especially as they're not likely to conflict with anything (so the conflict resolver accepts that more or less right away). /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403818: xserver-xorg: no video or keyboard after upgrading to sarge (deps too loose)
On Tue, Dec 19, 2006 at 09:22:34PM -0500, David Nusinow wrote: > I can't imagine what that would be... I'd love to know. Was this on x86? It was on x86, yes. > Perhaps for video 'xserver-xorg-video-all | xserver-xorg-video-vesa' in the > recommends. That could work as well; OTOH a well-functioning aptitude (ie. one not faced with conflicts) would already pull in xserver-xorg-video-all, so I'm not sure if there's a particularly good reason to put -all in the recommends. I still think the best basic idea is to give aptitude a simple choice to work with, with no alternatives. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#929451: linking shaders twice fails, fixed by rebuilding the package
Package: libgl1-mesa-dri Version: 18.3.4-2 Severity: important Hi, I've got a problem that essentially breaks Nageru on my Haswell laptop; if you try to link a GLSL program twice (to get a new program number for it), the second attempt fails with Error linking program: error: vertex shader lacks `main' This fails with libgl1-mesa-dri from testing _only_ (both unstable and experimental are fine), and even more interesting; if I recompile mesa 18.3.4-2 myself with zero changes and install the resulting libgl1-mesa-dri package, the problem goes away! So either the build was made on a broken machine, or something in unstable has changed in the meantime. So, please binNMU libgl1-mesa-dri for at least amd64, since this is likely to break a fair amount of applications. -- Package-specific info: glxinfo: name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_no_config_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_context_flush_control, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync GLX version: 1.4 GLX extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel Open Source Technology Center (0x8086) Device: Mesa DRI Intel(R) Haswell Mobile (0xa16) Version: 18.3.4 Accelerated: yes Video memory: 1536MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.1 OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.4 OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: GL_3DFX_texture_compression_FXT1, GL_AMD_conservative_depth, GL_AMD_draw_buffers_blend, GL_AMD_multi_draw_indirect, GL_AMD_query_buffer_object, GL_AMD_seamless_cubemap_per_texture, GL_AMD_shader_trinary_minmax, GL_AMD_vertex_shader_layer, GL_AMD_vertex_shader_viewport_index, GL_ANGLE_texture_compression_dxt3, GL_ANGLE_texture_compression_dxt5, GL_APPLE_object_purgeable, GL_ARB_ES2_compatibility, GL_ARB_ES3_1_compatibility, GL_ARB_ES3_compatibility, GL_ARB_arrays_of_arrays, GL_ARB_base_instance, GL_ARB_blend_func_extended, GL_ARB_buffer_storage, GL_ARB_clear_buffer_object, GL_ARB_clear_texture, GL_ARB_clip_control, GL_ARB_compressed_texture_pixel_storage, GL_ARB_comput
Bug#929451: linking shaders twice fails, fixed by rebuilding the package
On Thu, May 23, 2019 at 08:27:40PM +0200, Steinar H. Gunderson wrote: > This fails with libgl1-mesa-dri from testing _only_ (both unstable > and experimental are fine), and even more interesting; if I recompile > mesa 18.3.4-2 myself with zero changes and install the resulting > libgl1-mesa-dri package, the problem goes away! So either the build > was made on a broken machine, or something in unstable has changed > in the meantime. I figured out why a rebuild helped; it's a shader cache problem, and Mesa's shader cache is keyed (among others) on the build ID. Unfortunately, even after clearing the shader cache, I can provoke these issues with a bit of work. So something is corrupting the shader cache. > So, please binNMU libgl1-mesa-dri for at least amd64, since this is > likely to break a fair amount of applications. You can disregard this part, then. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#929451: linking shaders twice fails, fixed by rebuilding the package
On Thu, May 23, 2019 at 08:27:40PM +0200, Steinar H. Gunderson wrote: > This fails with libgl1-mesa-dri from testing _only_ (both unstable > and experimental are fine), and even more interesting; if I recompile > mesa 18.3.4-2 myself with zero changes and install the resulting > libgl1-mesa-dri package, the problem goes away! So either the build > was made on a broken machine, or something in unstable has changed > in the meantime. I figured out why a rebuild helped; it's a shader cache problem, and Mesa's shader cache is keyed (among others) on the build ID. Unfortunately, even after clearing the shader cache, I can provoke these issues with a bit of work. So something is corrupting the shader cache. > So, please binNMU libgl1-mesa-dri for at least amd64, since this is > likely to break a fair amount of applications. You can disregard this part, then. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#929451: linking shaders twice fails, fixed by rebuilding the package
On Thu, May 23, 2019 at 10:09:21PM +0200, Steinar H. Gunderson wrote: > Unfortunately, even after clearing the shader cache, I can provoke these > issues with a bit of work. So something is corrupting the shader cache. I tracked this to https://bugs.freedesktop.org/show_bug.cgi?id=110872 which is related to a Qt bug: https://bugreports.qt.io/browse/QTBUG-76299 Given that it breaks Nageru on i965 (and probably not a lot of other things, given the analysis), but is unlikely to be fixed in Mesa, at least not for buster, I'm going to add a workaround to Nageru. (It's possible Qt should have a fix, too, but it's unlikely to be RC for Qt.) Reassigning to Nageru and making RC. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#918960: libgl1-mesa-dri: lacks valgrind support
tags 918960 + patch thanks On Fri, Jan 11, 2019 at 01:29:35AM +0100, Momchil wrote: > I would like you to compile the library with valgrind support turned on or > create a separate package where the feature is turned on. This allows one to > use valgrind to check for memory leaks in applications. In case the feature is > not compiled, valgrind reports tons of memory problems with applications using > OpenGL for example. Note that this is utterly trivial; just add a Build-Dependency on valgrind, and the build system will take care of the rest. My understanding is that this has zero impact on runtime performance; it just adds a few very short instruction sequences after each DRM allocation, only picked up when running under Valgrind. I tried rebuilding with the b-d in question, and indeed, the torrent of Valgrind errors went away almost entirely. > Please also refer to my other report Bug#918895: libdrm2: > lacks valgrind support. It looks as if libdrm2 is already built with Valgrind support. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#832549: xserver-xorg: X now defaults to using built-in modesetting video driver on Intel. X no longer functioned
On Tue, Jul 26, 2016 at 02:57:47PM -0400, jackson wrote: > Contents of /etc/X11/xorg.conf: > --- > Section "Device" > Identifier "Intel" > Driver "intel" > # Option "AccelMethod" "uxa" > EndSection X broke for me, too -- the Intel driver somehow isn't autodetected anymore, which leads to using some unaccelerated driver (which breaks e.g. OpenGL pretty badly). Xorg -configure loads the Intel driver, but it doesn't detect any cards. Forcing the intel driver in xorg.conf (as in the quoted text) remediates the problem. Shouldn't this be RC? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#832549: xserver-xorg: X now defaults to using built-in modesetting video driver on Intel. X no longer functioned
On Thu, Jul 28, 2016 at 07:34:45PM +0200, Julien Cristau wrote: >> X broke for me, too -- the Intel driver somehow isn't autodetected anymore, >> which leads to using some unaccelerated driver (which breaks e.g. OpenGL >> pretty badly). > The intel X driver not being loaded is on purpose. That shouldn't > result in anything being unaccelerated, though, so please file your own > bug about that. Which package should I file against? /* Steinar */ -- Homepage: https://www.sesse.net/
