Bug#643763: dexconf fails due to missing xserver-xorg/config/device/bus_id
> Switching to testing would give you a more ârecentâ stack, but you could > drag a lot of breaka^Wfun with other packages and upgrade paths which > might not be well tested yet. ;-) I'll settle for the fun ;-) Eddy. -- 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/E1RWRRu-0005xj-KA@whorl
Bug#643763: dexconf fails due to missing xserver-xorg/config/device/bus_id
> There's 1:6.14.2-1~bpo60+1 (and a newer X stack) in squeeze-backports if > you want to try something. Thanks - I interpolate that this newer X stack exists in a more recent release of Debian. The given machine's /etc/issue reports Debian 6.0; which I see is squeeze, with wheezy in testing. I take it an upgrade to wheezy should be sufficient (and probably more robust than mixing versions ...), Eddy. -- 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/E1RWPxu-0005sc-Fu@whorl
Bug#643763: dexconf fails due to missing xserver-xorg/config/device/bus_id
> This crash is fixed in the current upstream driver (as of 6.14.1), but > only by disallowing rotation when acceleration is disabled. ah. That is sad. >> Build Operating System: Linux 2.6.37-trunk-amd64 x86_64 Debian > [...] >> (--) RADEON(0): Chipset: "ATI Radeon HD 5450" (ChipID = 0x68f9) > [...] >> (II) RADEON(0): GPU accel disabled or not working, using shadowfb for KMS > > So this is your core problem, and AFAICT it's basically due to the X > radeon driver being too old to properly support your card. and, I take it, no newer radeon driver for X is available. The perils of letting sysadmin give me a shiny new box with a very modern graphics card, I guess :-( Thanks for at least identifying what's wrong ! Eddy. -- 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/E1RW8EY-000149-F1@whorl
Bug#643763: dexconf fails due to missing xserver-xorg/config/device/bus_id
Hi again Julien, and thanks for your assistance. > Section "Monitor" > Identifier "" > Option "Rotate" "left" > EndSection I take it you mean an xorg.conf containing *only* this section will suffice; any content in xorg.conf will be merged to what would have been used without it. I'm not clear on what "" entails. I have no command named randr. I have one named xrandr; and its man page talks about outputs, but it appears to expect me to know the name of the output already. How do I query the system to obtain the relevant name ? I would previously have found that by looking at the name dexconf wrote into the xorg.conf file I can't get it to generate ... When I run xrandr with no args, it reports: Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 8192 x 8192 DVI-0 unknown connection (normal left inverted right x axis y axis) 1360x768 59.8 1152x864 60.0 1024x768 60.0 800x60060.3 640x48059.9 DVI-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 367mm x 275mm 1600x1200 60.0*+ 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.1 60.0 800x60075.0 60.3 640x48075.0 60.0 720x40070.1 Which part of that is the "output" name ? Given that DVI-1 has *+ after one of its modes, I take it it's the one that's actually connected to the running X session. However, using DVI-1 as the output name above and restarting xdm, I render the new box unusable - xdm clearly shut down and tried to restart, but then the screen went black and no longer responded to the keyboard - fortunately, I can ssh into it to fix that. (My attempts to start an X session are currently hampered by something not liking the call to shopt in my ~/.bashrc and the uses of the "function" built-in in ~/.bash_profile, even though whatever's having the problem claims SHELL is /bin/bash - and, obviously, I can see no reason why anything but bash would be reading these files anyway - but I'll fight with that later. I was able to get xrandr to run before that hit ...) Eddy. -- 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/E1R9NUK-0001EW-98@whorl
Bug#643763: dexconf fails due to missing xserver-xorg/config/device/bus_id
>> Bug: a failing run of dexconf should at least report this ! >> Reconfiguring xserver-xorg should, ideally, at least fail with $? set >> when dexconf fails. >> > Actually dexconf should stop existing. OK, and what will create my xorg.conf file ? Or what do I need to configure, instead, to tell the X server I want it to use my screen in portrait mode ? Eddy. -- 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/E1R9M9K-00018Q-An@whorl
Bug#555647: x11-xserver-utils: xrandr -o left leaves xdm, after I logout, unresponsive, with no login prompt
> Sorry for the delay, in the mean time did this get fixed, in squeeze, > testing or unstable ? I'll need to log out to test, which would currently be rather disruptive - so there may be some delay ! But I'll try to find time for a test soon. Eddy. -- 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/E1PzXb2-00046b-TJ@whorl
Bug#555647: x11-xserver-utils: xrandr -o left leaves xdm, after I logout, unresponsive, with no login prompt
> I use xrandr -o left in my .xsession so that I can use my screen in > portrait mode. I'm now achieving the equivalent effect by adding Option "Rotate" "left" to Section "Monitor" of my /etc/X11/xorg.conf (which avoids the font problems I had with xrandr -o left) and now find that xdm always hangs after I log out (where, previously, it only used to hang if I ran xrandr -o -left in my user session). When the X session is hanging, after I've logged out, I find that /etc/init.d/xdm stop fails, claiming that the xdm.pid file doesn't exist, even though ps reports that the xdm process is still running. I notice that xmd has two child processes: USER PID PPIDSZVSZ RSZ NI CMD root 17331 1 1399 5596 940 0 /usr/bin/xdm root 20618 17331 6763 27052 15008 0 /usr/bin/X :0 vt7 -nolisten tcp -auth /var/lib/xdm/authdir/authfiles/A:0-chlHyX root 20622 17331 2104 8416 5236 0 -:0 When logging out has hung the X session, killing the last (which has a symlink to /usr/bin/xdm as its /proc/20622/exe) causes xdm to exit; whereas killing the /usr/bin/X process persuades the xdm process to start a new X login prompt, which works as usual. Eddy. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555648: x11-xserver-utils: xrandr -o left: starts up with squished fonts; aspect ratio not adjusted ?
I've now added Option "Rotate" "left" to Section "Monitor" in my /etc/X11/xrdb.conf so that xrdb operates in portrait mode ab initio, which avoids the need to invoke xrandr -o left, hence avoids the problem. However, it would obviously be better if xrandr and the font infrastructure played nicely with one another anyway ... Eddy. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555648: x11-xserver-utils: xrandr -o left: starts up with squished fonts; aspect ratio not adjusted ?
Package: x11-xserver-utils Version: 7.4+2 Severity: normal In my .xsession, I run xrandr -o left which lets me use my screen in portrait mode. (Many modern flat screens, including the Dell one I'm using, have a pivot at the back that lets one turn them sideways.) Unfortunately, doing this gets me a bunch of broken fonts. I exec fvwm at the end of .xsession and it comes up with menus that are barely readable: it looks as if the fonts have got their metrics set for the original orientation, or something like that. Until recently, it has been the case that I can simply exit and log in again; the login prompt from xdm came up in the right orientation for portrait mode and I got started sensibly on the second atttempt, with perfectly sensible fonts. I'll report the new problem separately, that now prevents me using that work-around ... it's rather more severe ! I don't know what makes that go wrong, but clearly xrandr needs to do something differently to ensure The Right fonts show up once X gets going - perhaps it needs to restart xfs ? I don't know how any of this works, though. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages x11-xserver-utils depends on: ii cpp 4:4.3.3-9+nmu1 The GNU C preprocessor (cpp) ii libc6 2.10.1-5 GNU C Library: Shared libraries ii libice6 2:1.0.5-1 X11 Inter-Client Exchange library ii libsm62:1.1.1-1 X11 Session Management library ii libx11-6 2:1.2.2-1 X11 client-side library ii libxau6 1:1.0.5-1 X11 authorisation library ii libxaw7 2:1.0.6-1 X11 Athena Widget library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxi62:1.2.1-2 X11 Input extension library ii libxmu6 2:1.0.4-2 X11 miscellaneous utility library ii libxmuu1 2:1.0.4-2 X11 miscellaneous micro-utility li ii libxrandr22:1.3.0-2 X11 RandR extension library ii libxrender1 1:0.9.4-2 X Rendering Extension client libra ii libxt61:1.0.6-1 X11 toolkit intrinsics library ii libxtrap6 2:1.0.0-5 X11 event trapping extension libra ii libxxf86misc1 1:1.0.1-3 X11 XFree86 miscellaneous extensio ii libxxf86vm1 1:1.0.2-1 X11 XFree86 video mode extension l ii x11-common1:7.4+4X Window System (X.Org) infrastruc x11-xserver-utils recommends no packages. Versions of packages x11-xserver-utils suggests: pn cairo-5c (no description available) pn nickle (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555647: x11-xserver-utils: xrandr -o left leaves xdm, after I logout, unresponsive, with no login prompt
Package: x11-xserver-utils Version: 7.4+2 Severity: normal I use xrandr -o left in my .xsession so that I can use my screen in portrait mode. However, after a recent upgrade, I find that when I log out (exit fvwm) I don't get the xdm login prompt I'm expecting. I have to restart xdm. Previously, when I logged out, xdm's login prompt was correctly oriented for the portrait mode in which I was using the screen - which was potentially an issue, since a feature of my session survived to affect whoever might log in after me. However, this worked nicely for me; in particular, it facilitated a work-around for a problem with the fonts used in portrait mode, the first time I logged in; logging out and back in fixed it. I can no longer do that. Tell me what I need to log to help diagnose the problem ... -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages x11-xserver-utils depends on: ii cpp 4:4.3.3-9+nmu1 The GNU C preprocessor (cpp) ii libc6 2.10.1-5 GNU C Library: Shared libraries ii libice6 2:1.0.5-1 X11 Inter-Client Exchange library ii libsm62:1.1.1-1 X11 Session Management library ii libx11-6 2:1.2.2-1 X11 client-side library ii libxau6 1:1.0.5-1 X11 authorisation library ii libxaw7 2:1.0.6-1 X11 Athena Widget library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxi62:1.2.1-2 X11 Input extension library ii libxmu6 2:1.0.4-2 X11 miscellaneous utility library ii libxmuu1 2:1.0.4-2 X11 miscellaneous micro-utility li ii libxrandr22:1.3.0-2 X11 RandR extension library ii libxrender1 1:0.9.4-2 X Rendering Extension client libra ii libxt61:1.0.6-1 X11 toolkit intrinsics library ii libxtrap6 2:1.0.0-5 X11 event trapping extension libra ii libxxf86misc1 1:1.0.1-3 X11 XFree86 miscellaneous extensio ii libxxf86vm1 1:1.0.2-1 X11 XFree86 video mode extension l ii x11-common1:7.4+4X Window System (X.Org) infrastruc x11-xserver-utils recommends no packages. Versions of packages x11-xserver-utils suggests: pn cairo-5c (no description available) pn nickle (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#475534: x11-apps: oclock fails to show updated time, apparently because repainting hands in wrong colour
I've rotated my screen using xrandr -o left to use it in portrait mode and, to my pleasant surprise, the oclock now works as it always used to. There doesn't appear to have been an upgrade to x11-apps since I reported the bug, but it has been some weeks since I last rebooted or even restarted my X server, so it's possible something else changed in the mean time. Either that or xrandr did some magic that overcame whatever was breaking it; or the change in screen position (it sits in the top right of the screen, which now has a much lower x co-ordinate) was relevant. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475534: x11-apps: oclock fails to show updated time, apparently because repainting hands in wrong colour
Interesting. My X session tanked, forcing a re-start. My new oclock remained frozen in time until I switched to a virtual console and back, at which point the frozen hands went black, except for a triangle of yellow where one of them intersects the position it should be in. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475534: x11-apps: oclock fails to show updated time, apparently because repainting hands in wrong colour
Package: x11-apps Version: 7.3+1 Severity: normal A power-cut just forced me to reboot into 2.6.24-1-686, having previously been on a 2.6.18. Most X-related things were restarted within the last two weeks when I did an /etc/init.d/xdm restart, but some have doubtless been updated since. After the power-cut, my oclock has always been stopped. Its hands don't move, although they do change colour I find that an xclock works fine. My fvwm init.hook fires off oclock using + I Exec exec oclock -transparent -geometry -0+0 and post.hook sets Style * SloppyFocus Style oclockNeverFocus, NoTitle, Sticky, NoHandles, StaysOnTop I've started a separate X session, startx -- :1, running fvwm with nothing but an xterm and the xplanet root window (that somehow knew to start up, despite my having moved aside my default config), from which I started oclock -transparent; I see the oclock's hands in their initial position mostly painted black; or, when I had to clear xscreensaver, the green that xscreensaver was doing; so it looks like a failure to repaint. It looks as if the part that remains yellow is the intersection of the initial position of the hands and the position they should currently be in; but the current position is not otherwise drawn. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages x11-apps depends on: ii cpp 4:4.2.2-2 The GNU C preprocessor (cpp) ii libc6 2.7-10 GNU C Library: Shared libraries ii libfontconfig12.5.0-2generic font configuration library ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libpng12-01.2.15~beta5-3 PNG library - runtime ii libsm62:1.0.3-1+b1 X11 Session Management library ii libx11-6 2:1.0.3-7 X11 client-side library ii libxaw7 2:1.0.4-1 X11 Athena Widget library ii libxcursor1 1:1.1.9-1 X cursor management library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxft2 2.1.12-2 FreeType-based font drawing librar ii libxkbfile1 1:1.0.5-1 X11 keyboard file manipulation lib ii libxmu6 2:1.0.4-1 X11 miscellaneous utility library ii libxmuu1 2:1.0.4-1 X11 miscellaneous micro-utility li ii libxrender1 1:0.9.4-1 X Rendering Extension client libra ii libxt61:1.0.5-3 X11 toolkit intrinsics library ii x11-common1:7.2-5X Window System (X.Org) infrastruc ii fvwm 1:2.5.25-1 F(?) Virtual Window Manager, version 2.5 x11-apps recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423014: console's last three lines become inaccessible once xdm start up
> Strange, I am not sure what to do with this bug then. Understandable. > Will you have a chance to try the old CRT again? No - it's been junked (see below for why), that's why I replaced it. This might justify closing the bug as "hardware fault". > Are you sure the bug disappeared because you switched the display > and not because of an upgrade at the same time? The bug persisted through an upgrade shortly before, which broke X support for the old CRT; and we (a sysadmin and I) were unable to work out what was the matter with it; but a replacement display workd fine, so we blamed the CRT. However, in investigating that, we were routinely using the console, which *was* missing its bottom three lines. So I don't believe the disappearance was due to the software upgrade. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423014: console's last three lines become inaccessible once xdm start up
Incidentally, this bug has become unreproducible since I switched from using the old CRT to using a shiny new flat screen. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445104: xscreensaver: aborts X session if I let the log-back-in screen time out while switched to a virtual console
> Thanks, I'm reassigning this bug to the X server. The complete log and > your xorg.conf would be useful. OK. X Window System Version 1.3.0 Release Date: 19 April 2007 X Protocol Version 11, Revision 0, Release 1.3 Build Operating System: Linux Debian (xorg-server 2:1.3.0.0.dfsg-12) Current Operating System: Linux whorl 2.6.21-2-686 #1 SMP Wed Jul 11 03:53:02 UTC 2007 i686 Build Date: 09 August 2007 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Oct 3 10:51:22 2007 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Dell 2007FPb" (**) | |-->Device "Intel Corporation 82915G/GV/910GL Integrated Graphics Controller" (**) |-->Input Device "IBM-UK Keyboard" (**) |-->Input Device "Logitech Mouse" (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType (==) RgbPath set to "/etc/X11/rgb" (==) ModulePath set to "/usr/lib/xorg/modules" (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) No APM support in BIOS or kernel (II) Loader magic: 0x81e5140 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 1.2 X.Org XInput driver : 0.7 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: "pcidata" (II) Loading /usr/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.2 (++) using VT number 7 (WW) xf86OpenConsole: setpgid failed: Operation not permitted (WW) xf86OpenConsole: setsid failed: Operation not permitted (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,2580 card 1028,0179 rev 04 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,2581 card , rev 04 class 06,04,00 hdr 01 (II) PCI: 00:02:0: chip 8086,2582 card 1028,0179 rev 04 class 03,00,00 hdr 80 (II) PCI: 00:02:1: chip 8086,2782 card 1028,0179 rev 04 class 03,80,00 hdr 80 (II) PCI: 00:1c:0: chip 8086,2660 card , rev 03 class 06,04,00 hdr 81 (II) PCI: 00:1c:1: chip 8086,2662 card , rev 03 class 06,04,00 hdr 81 (II) PCI: 00:1d:0: chip 8086,2658 card 1028,0179 rev 03 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2659 card 1028,0179 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,265a card 1028,0179 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:3: chip 8086,265b card 1028,0179 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,265c card 1028,0179 rev 03 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,244e card , rev d3 class 06,04,01 hdr 81 (II) PCI: 00:1e:2: chip 8086,266e card 1028,0179 rev 03 class 04,01,00 hdr 00 (II) PCI: 00:1f:0: chip 8086,2640 card , rev 03 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,266f card 1028,0179 rev 03 class 01,01,8a hdr 00 (II) PCI: 00:1f:2: chip 8086,2651 card 1028,0179 rev 03 class 01,01,8f hdr 00 (II) PCI: 00:1f:3: chip 8086,266a card 1028,0179 rev 03 class 0c,05,00 hdr 00 (II) PCI: 02:00:0: chip 14e4,1677 card 1028,0179 rev 01 class 02,00,00 hdr 00 (II) PCI: End of PCI scan (II) Intel Bridge workaround enabled (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,4), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0002 (VGA_EN is cleared) (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xdfd0 - 0xdfdf (0x10) MX[B] (II) PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:28:0), (0,2,2), BCTRL: 0x0002 (VGA_EN is cleared) (II) Bus 2 non-prefetchable memory range: [0] -1 0 0xdfc0 - 0xdfcf (0x10) MX[B] (II) PCI-to-PCI bridge: (II) Bus 3: bridge is at (0:28:1), (0,3,3), BCTRL: 0x0002 (VGA_EN is cleared) (II) Bus 3 non-prefetchable memory range: [0] -1 0 0xdfb0 - 0xdfbf (0x10) MX[B] (II) Subtractive PCI-to-PCI bridge: (II) Bus 4: bridge is at (0:30:0), (0,4,4), BCTRL: 0x0002 (VGA_
Bug#432847: /usr/bin/xload: xload needs a way to limit range of values it can display
> Unfortunately, most tiny X programs like this one usually don't get much > maintenance. So you should probably try to come with a patch if you > really want this to be implemented :/ Fair enough. If I find the time ... Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#432847: /usr/bin/xload: xload needs a way to limit range of values it can display
> This could readilly enough be remedied by providing a command-line > option, --clip-at=n, to tell xload to not try to display any load > level above n. More fancy solutions are possible. closer inspection of the man page suggests this could be implemented as an optional second value for -scale: -scale integer[,integer] This option controls the number of tick marks in the histogram, where one division represents one load average point. If the load goes above the first number, xload shall create more divisions, but it shall never use fewer than this number. The default is 1. If the second number is supplied, xload shall not create more than this many divisions; if load goes above this value, the histogram shall be clipped. The default is to always have enough divisions to display the highest load seen during the displayed time interval. or similar. I also notice that the man page says: -jumpscroll number of pixels The number of pixels to shift the graph to the left when the graph reaches the right edge of the window. The default value is 1/2 the width of the current window. Smooth scrolling can be achieved by setting it to 1. I do not pass this argument, but get smooth scrolling as if I were setting it to 1. I have never seen the graph shift to the right by half the width of the window. Given that I like the smooth scrolling effect, I'd argue for changing the documentation to match the observed behaviour ;-> Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#432847: /usr/bin/xload: xload needs a way to limit range of values it can display
Package: x11-apps Version: 0.1 Severity: wishlist File: /usr/bin/xload The vertical scale of xload adjusts to accommodate the highest load level. It has horizontal lines to indicate the vertical scale. A high enough load shall cause these lines to be so closely spaced that there is no space between them: the entire display is then white (I have reverse video set, so the background is black and scale lines are white) and I can no longer see the load varying, on account of the lines. Modern machines can endure quite immense loads, so this problem can readilly arise (I routinely get it when running make -j -l 12, if some of the processes make first fires off do very vigorous things once started). The machine is happy, but xload becomes useless ! If the load has a transient spike, the vertical scale adapts to let the spike's top be displayed: if the spike is high enough, xload becomes useless until the spike has scrolled off the left hand end - or until I kill it and start a fresh xload, losing all the data that was on display for the prior four hours (yes, xload is almost the full width of my screen). Note that setting the foreground colour of xload doesn't help: the grid lines are drawn on top of the load data, so would hide it. This could readilly enough be remedied by providing a command-line option, --clip-at=n, to tell xload to not try to display any load level above n. More fancy solutions are possible. It may be sufficient simply to draw the load data on top of the scale lines; then -foreground=red would suffice to make the load graph's shape visible, even when the scale lines are so closely packed as to form a featureless background (giving no indication of scale - other than "OMG that's high !"). If the vertical scale is huge enough that the horizontal lines use up more than (say) half of the pixels available for vertical height (at this point, it's possible - but getting hard - to read the display), xload could drop the granularity of its vertical scale; only display one in 10 of the horizontal lines, for example. Naturally, this would require some way to indicate that the scale has been adjusted; e.g. the load-level difference between horizontal lines could be displayed in the top left corner of the chart. Of course, the value of 10 (the base of the number system in use) could be controlled by a command-line parameter; or it could just be hard-coded to ten or 0x10. Alternatively, the horizontal lines could be dashed, with multiples of 10 using longer dashes (and multiples of 100 using longer ones yet). The dashes for adjacent values should be staggered, so that they don't simply from a solid vertical column (hiding data in the interval it spans). -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages x11-apps depends on: ii cpp 4:4.1.1-15 The GNU C preprocessor (cpp) ii libc6 2.5-9+b1 GNU C Library: Shared libraries ii libfontconfig12.4.2-1.2 generic font configuration library ii libice6 1:1.0.3-2 X11 Inter-Client Exchange library ii libpng12-01.2.15~beta5-2 PNG library - runtime ii libsm62:1.0.3-1 X11 Session Management library ii libx11-6 2:1.0.3-7 X11 client-side library ii libxaw7 1:1.0.3-3 X11 Athena Widget library ii libxcursor1 1:1.1.8-2 X cursor management library ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar ii libxft2 2.1.12-2 FreeType-based font drawing librar ii libxkbfile1 1:1.0.4-1 X11 keyboard file manipulation lib ii libxmu6 1:1.0.3-1 X11 miscellaneous utility library ii libxmuu1 1:1.0.3-1 X11 miscellaneous micro-utility li ii libxrender1 1:0.9.2-1 X Rendering Extension client libra ii libxt61:1.0.5-3 X11 toolkit intrinsics library ii x11-common1:7.2-5X Window System (X.Org) infrastruc x11-apps recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423014: console's last three lines become inaccessible once xdm start up
Interestingly, when aptitude fires up the console-graphical package configuration tool, during installation of new packages, it manages to put the OK selector where I *can* see it, even though aptitude itself fails to show me its last three lines. (For example, when asking me to hit return to continue, it does so where I can't see it; I have no way to know whether it's showing that prompt or just taking a long time to install some package that it's mentioned on a line I can't see.) Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423014: console's last three lines become inaccessible once xdm start up
Hi again Julien, Everone else went home, so I have a chance to break things^W^W experiment. Upon re-booting and actually checking what resize and $LINES say when the X server hasn't messed things up, I find that I've mis-described this bug. The normal state does in fact have 28 lines; when the X server starts up, something causes the console to be only able to display 25 of them; I think these are slightly taller, since they fill the same amount of screen. None the less, screen resizing via the hardware controls doesn't help. So something has changed the console - maybe its font ? Any idea how I can ask it about that ? So, sorry about having it partially back-to front; but the same consequences flow from it ! >> I'm guessing that if I run dpkg-reconfigure on the xserver package, >> it'll ask me to select a driver and I can change from vesa to i810. > > That, or replace vesa with i810 in /etc/X11/xorg.conf and restart X. I had to reboot anyway (to restore normal mode), so might as well use the brute force approach and let the system do any updates it deems prudent. This also meant that I saw that the part of the configuration which offered me a choice between using the frame buffer and not using it was set to not use it. I left it that way. Interestingly, the reconfigure has put my Modes lines into the usual order, with 1600x1200 first, and xdm has no problem starting up; so clearly whatever problem it was having (before I bodged the order as described previously) has been solved. >> Please suggest a command that'll reveal whether I have an fb console. > Maybe lsmod will show whether a fb driver is loaded. lsmod | grep fb yielded no output. The full output of lsmod contained 58 lines but I have no delusions of understanding it. Do you want to see it all ? lsmod | grep i810 yielded i810_audio 32916 0 ac97_codec 17196 1 i810_audio soundcore 9248 2 i810_audio,snd Rebooting without xdm (and confirming that I was still in normal mode), I logged in as a non-privileged user (me) and ran startx (with no args); it started up X just fine, and all my consoles went into "only displaying 25 lines" mode, as before. So your guess that xdm is not the culprit is vindicated. I'm now running (and was when testing startx) with Section "Device" Identifier "Intel Corporation 82915G/GV/910GL Integrated Graphics Controller" Driver "i810" BusID "PCI:0:2:0" EndSection and I still get the (++) using VT number 7 (WW) xf86OpenConsole: setpgid failed: Operation not permitted (WW) xf86OpenConsole: setsid failed: Operation not permitted which you deemed weird earlier. If you want full output from your earlier script, just ask and I can do that again. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423014: console's last three lines become inaccessible once xdm start up
>> Section "Device" >> Identifier "Intel 82915G/GV/910GL" >> Driver "vesa" >> BusID "PCI:0:2:0" >> EndSection >> > Did you try the "i810" driver instead of "vesa"? > Also, do you use a fb console? This is the point where I should point out that I am not a sysadmin. (I *have* been using X since the early '90s, so I can work out how to use startx manually, though.) Consequently, it'll be worth going into slightly more detail when asking me for more information, so I know what to do to discover the answers you need. Relevant command-lines should suffice. I'm guessing that if I run dpkg-reconfigure on the xserver package, it'll ask me to select a driver and I can change from vesa to i810. However, I've no idea how to find out whether I'm using an fb console. I have six virtual consoles and an X session, accessible by Alt+F[1-7], with help from Ctrl if coming from the X session. Please suggest a command that'll reveal whether I have an fb console. > This is weird... ah. Well, let's see where it goes ... Thanks for your help, Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423014: console's last three lines become inaccessible once xdm start up
Package: xdm Version: 1:1.1.4-3 Severity: critical Tags: security Justification: breaks unrelated software When I start up xdm, the console starts to imagine that there are three more lines available than actually exist. The console actually has 25 lines; but the console ttys think it has 28 lines. The resize command reports LINES=28. Even if I export LINES=25 and then fire up screen, my shell within screen has LINES=28. This means that I can't see the last three lines of output, once output gets to the bottom of the screen; it means that the emacs minibuffer and the aptitude dialog area are invisible; these don't even scroll into view after it's too late. This makes both emacs and aptitude almost impossible to use (hence: breaks unrelated software) and makes it almost impossible for root to do anything (hence: critical) if I follow the cautious policy of never letting root do anything in a window under X. The console becomes extremely difficult (and dangerous - see below) to use. It means that, when dpkg is installing a package, I'm apt to be asked some question I can't see and given a prompt I can't see and left waiting for the program to do something, so I end up hitting return and getting whatever the default was for the question I never saw being asked (on account of this last, I have added "security" as a tag); after that, dpkg begins producing more output and the entire dialog in which I have just played my blind part scrolls into view. Obviously, dpkg is not the only software (reportbug springs to mind) that relies on me to respond to prompts, after producing enough output that it's apt to be in the last three lines of the screen; nor is dpkg the only one for which random answers to unseen prompts may result in security-relevant disasters. The problem is *not* that the screen is mis-sized; if I shrink vertical on the screen, I still don't see the missing lines, though the lines I do see now fit into a smaller vertical span on my screen. In any case, if I suppress xdm's start-up (by adding an early exit 0 to /etc/init.d/xdm) I see normal console behaviour. It would not, however, surprise me if the problem is really with something else (xdm is merely triggering it); there may be some package doing something clever with the frame-buffer (bug I don't have a logo visible on screen). The problem *may* (but I'd be surprised) be related to the fact that my xorg.conf Display sections say Modes "1280x1024" "1152x864" "1024x768" "832x624" "800x600" "720x400" "640x480" "1600x1200" with the highest-resolution last (when I put it first, xdm failed to start up, albeit taking three tries at it before giving up; moving it to the end lets xdm start, after which Ctrl+Alt+keypad(-) suffices to get me to the highest resolution; leaving it on the default doesn't help the console, though). About three months ago, I saw this same problem, tried to find its cause, gave up and then was surprised, upon running the euro-test script (which failed) to find the problem had gone away. Today I moved desks, so re-booted (for the first time since the power outage three months ago - I love stable software ;-); and euro-test now passes, without fixing this problem. The fact that euro-test used to be able to fix it does imply that there must be some way to work around the problem (I'd be delighted if anyone can identify what; I've been carefully through euro-test without finding what it did that solved the problem). I tried /etc/init.d/console-screen.sh, invoked the same way euro-test was doing so three months ago, but that wasn't what was solving the problem. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages xdm depends on: ii cpp 4:4.1.1-15 The GNU C preprocessor (cpp) ii debconf [debconf-2.0] 1.5.13 Debian configuration management sy ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libice6 1:1.0.3-2X11 Inter-Client Exchange library ii libpam0g0.79-4 Pluggable Authentication Modules l ii libselinux1 1.32-3 SELinux shared libraries ii libsm6 1:1.0.2-2X11 Session Management library ii libx11-62:1.0.3-7X11 client-side library ii libxau6 1:1.0.1-2X11 authorisation library ii libxaw7 1:1.0.2-4X11 Athena Widget library ii libxdmcp6 1:1.0.2-2X11 Display Manager Control Protoc ii libxext61:1.0.1-2X11 miscellaneous extension librar ii libxinerama11:1.0.1-4.1 X11 Xinerama extension library ii libxmu6
Bug#410740: x11-common: please conflict with opera (<< 9.10-20061214.6)
Hi again Julien,
> If you can give us a more accurate version number to conflict with,
> we'll gladly change it.
OK, QA helpfully dug through the archive. The earliest public release
which included the fix was 9.00-20060616 (and all variant builds
included the fix). So the correct conflict would be
Conflicts: opera (<< 9.00-20060616)
Let us know if you run into any similar problems in future, we're
always eager to make our packages fit in better with distributions,
Edward Welbourne, for the Opera packaging team.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410740: x11-common: please conflict with opera (<< 9.10-20061214.6)
Hi Debian, I'm the Opera package maintainer. This bug doesn't say what the cause for the needed conflict is. However, the .5 (sarge) and .1 (static) builds released at the same time as the specified .6 (etch) build almost certainly had whatever fix was relevant, just as good as the .6 one did. So the final .6 suffix causes builds from the same day, but for sarge and older, to be in conflict. It may thus make some sense to drop this suffix. You would also do well to conflict with opera-static with version numbers matching the same constraint as opera. I've been told that the conflict has to do with the opera symlink in /usr/X11R6/bin/: I suppose the 20061214 build is the first official release your correspondent met in which the bug is fixed. However, the bug was fixed in 2006/May (and went into assorted unofficial builds between then and the official release). This should have gone into the 9.00 official release. So, if the conflict is about the symlink, you should be able to amend the version to 9.00-20060600 or similar. If the problem wasn't that symlink, I'd greatly appreciate it if you can tell me the details. I can ask our QA team to give a more precise date on the correct release version. If it's a bug I didn't notice myself fixing, I may need to port it to newer branches of the packaging scripts ! Edward Welbourne, for the Opera packaging team. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366695: xserver-xorg-video-i810: Depends on unavailable xserver-xorg-core on etch.
> This is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365134 >> It still failed, now saying that it couldn't make sense of the >> hardware ... Then I remembered that xorg had recently gone into >> many-package form, so went looking for a suitable >> xserver-xorg-video-* for the hardware reported to me by lspci: > xserver-xorg 6.9.0.dfsg.1-6 is still in testing, so you do not need > xserver-xorg-video-i810. Yup, once I'd worked round the xdm problems, it does indeed turn out that the xserver-xorg was OK - I just got mislead by the initial xdm problems into thinking the problem was in the server. Feel free to kill this bug as misguided ... Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366695: xserver-xorg-video-i810: Depends on unavailable xserver-xorg-core on etch.
> Remove the individual i810 driver package, it wouldn't install, so that was be a no-op ! > the xserver-xorg package in testing includes the driver you want. when I dpkg-reconfigure it, it starts by asking whether I want to let it autodetect: and says that it can't recognize what it finds. > If it doesn't support your card, then use the vesa driver duly configured to do so. This initially failed, for want of the X and then xrdb binaries in /usr/bin; they're in /usr/bin/X11/ (and dpkg -S doesn't know of a package that owns X), so I hard-linked them and my X server starts up fine. That sufficed to get xdm started (yay), though I notice it starts about seven processes, each with parent PID 1, each allegedly running the xdm binary. Odd, but working - thank you for your guidance. > Second, the xdm bug is an actual bug in the dependencies that will only > affect testing until the rest of X11R7 migrates. For that you'll just have > to be patient. Use an alternate *dm or just use startx for the time being. or cope with some bodgery (see above). > We're working hard on getting all the pieces in to testing, I'd noticed - lots of interesting change has been going on when I update. Good luck getting it all to work. > for now every part of the 6.9 release except for xdm will work just > as it always has. OK, I'll remember to treat xdm with care, Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366695: xserver-xorg-video-i810: Depends on unavailable xserver-xorg-core on etch.
> http://packages.debian.org/xserver-xorg-core Yes, I know that package is not available on testing. That's why I submitted the bug against xserver-xorg-video-i810, not against xserver-xorg-core. http://packages.debian.org/xserver-xorg-video-i810 says it's available on testing. It * appears to be my best bet for support for my video card, * depends on xserver-xorg-core and, thus, * is broken, on testing. Before the xserver-xorg package split off its per-device packages, it supported my video card on testing. Now, testing does not support that video card. I am suddenly without X server. I'm hoping testing shall support my video card, one way or another, by the time I get back from the fortnight's holiday that I needed to get a bunch of stuff done before, Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366695: xserver-xorg-video-i810: Depends on unavailable xserver-xorg-core on etch.
Package: xserver-xorg-video-i810 Version: 1:1.5.1.0-2 Severity: grave Justification: renders package unusable Due to a power outage, I had to re-boot my etch box after some months, during which I'd updated it, so am now using the modern xserver-xorg-* package fragments, where I was using a more monolithic xorg when last I booted. When re-booted, I got no xdm up. Initially, this was because /etc/init.d/xdm referred to /usr/bin/X11/xdm, which no longer exists. When I amended that, I still got failure, since /etc/X11/default-display-manager had also survived, and referred to the same xdm. Reverting the prior amend and inserting a symlink in /usr/X11R6/bin/ solved those problems, so that xdm at least *tried* to start up. It still failed, now saying that it couldn't make sense of the hardware (I've had a very grim six hours since then, of trying to get my machine back in an X-compatible state, without success, so don't remember the exact wording; having now reverted to as close as I can remember to that state, I lack the /usr/bin/X that xdm wants). Then I remembered that xorg had recently gone into many-package form, so went looking for a suitable xserver-xorg-video-* for the hardware reported to me by lspci: :00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Express Chipset Family Graphics Controller (rev 04) It looks like the package I want is xserver-xorg-video-i810; but, when I tried to install that, it was broken, because it depends on xserver-xorg-core, which is not present in etch. So I can't actually install this package to find out whether it really is what I need. There seems little point making a package available to testing when it depends on a package unavailable to testing. Carving up a package into lots of little packages is a cool move, as long as all hardware set-ups whose support has moved into one of those packages are still catered to by a set-up on the branch (in this case testing) on which the big package provided support before its demise. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686-smp Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
