Re: Bug#711305: Loading i915 with modeset=1 disables display
On Mon, 15 Jul 2013, Julien Cristau wrote: On Mon, Jul 15, 2013 at 07:37:47 +0100, Robert de Bath wrote: On Sun, 9 Jun 2013, Julien Cristau wrote: If i915 doesn't give you a working display that's a kernel bug. Thanks, I'll add my voice to the multitude over there. Is it an X bug that X doesn't work with the driver if that option is set ? Is it a kernel bug ? Neither. OTOH, I think this should belong to at least one of them as it's a valid configuration option for the end user. They can reasonably choose to not have a graphic display unless they start X. In that way I think it's Both. X has a bug in that it can't configure the driver properly. The kernel is bugged in that it can't remove the driver and restore the display back to what it should be without a reboot. But I suppose both projects will look on this as some sort of reasonable limitation and so WONTFIX. Anyway, thankyou for your time. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- 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/alpine.DEB.2.00.1307161929301.21887@mayday
Bug#711305: Loading i915 with modeset=1 disables display
Package: xserver-xorg-video-intel Version: 2:2.13.0-7 This is an interaction of several different packages. Firstly, as you know the X video driver needs the i915 module to be loaded to work correctly; furthermore it requires the module to attempt to set the video mode during initilisation. Without this X doesn't load the video driver. With it the driver get loaded and works correctly. But, the kernel driver is buggy, if loaded with modeset=1 it will corrupt the display controller blanking the display. Unfortunatly, udev loads all drivers it can during the boot and uses the configuration set for modprobe. Luckily, someone seems to have though of this. When udev loads modules it supplies the --use-blacklist option, whereas X calls modprobe without the --use-blacklist option. So please set the contents of the file /etc/modprobe.d/i915-kms.conf to this: ! blacklist i915 options i915 modeset=1 ! This means it isn't loaded during boot and is loaded correctly when X starts. It also means that xinit true loads the video driver correctly and fixes the screen mode after booting vga=0x305 ... bit of an overkill but never mind that :-) It seems I also need it on one machine for the radeon driver; this being so I would suggest it's a good idea for all drivers using kms and requiring the kernel to do a modeset. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- 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/alpine.DEB.2.00.1306060856340.21887@mayday
Bug#404885: FOUND IT
It's in hw/xfree86/int10/xf86int10.c Function int1A_handler(xf86Int10InfoPtr pInt) For AX values 0xb108, 0xb109, 0xb10a, 0xb10b, 0xb10c and 0xb10d The entire contents of edi is used as a pci register number, only DI should be used. For this specific bios X86_ECX = pciReadLong(tag, X86_EDI); -- X86_ECX = pciReadLong(tag, X86_DI); in case 0xb10a: fixes my problem. Now I have a driver that's both stable and not too slow. :-) -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ On Wed, 25 Jul 2007, Julien Cristau wrote: On Fri, May 4, 2007 at 19:27:03 +0100, Robert de Bath wrote: Well, looks like I was wrong, the current unstable (1:7.2-3) locks up with 100% cpu. The process can be kill -9'd and the attached log is what remains. In addition after resetting the console I can see the messages: f000:5054: 01 ILLEGAL EXTENDED X86 OPCODE! XIO: fatal IO error 104 (Connection reset by peer) on X server :0.0 after 0 requests (0 known processed) with 0 events remaining. This is either a bug in the x86 emulator included in the X server, or a bug in your vbios. In either case, it'd probably work if you didn't use the vesa driver. Is there any particular reason you use it instead of an appropriate driver for your video card? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404885: xserver-xorg-video-vesa VERY SLOW
On Wed, 25 Jul 2007, Julien Cristau wrote: On Fri, May 4, 2007 at 19:27:03 +0100, Robert de Bath wrote: Well, looks like I was wrong, the current unstable (1:7.2-3) locks up with 100% cpu. The process can be kill -9'd and the attached log is what remains. In addition after resetting the console I can see the messages: f000:5054: 01 ILLEGAL EXTENDED X86 OPCODE! XIO: fatal IO error 104 (Connection reset by peer) on X server :0.0 after 0 requests (0 known processed) with 0 events remaining. This is either a bug in the x86 emulator included in the X server, or a bug in your vbios. In either case, it'd probably work if you didn't use the vesa driver. Is there any particular reason you use it instead of an appropriate driver for your video card? To some extent you're right, the kernel frame buffer works, the svgalib driver (chipset VESA) works and debian stable xserver-xorg-video-vesa driver works. The current card specific driver also works (and it uses vesa) but bugs 402673 and 407620 make it a pain to use, especially as 402673 understates the problem somewhat. All those except the older xserver work in linear mode. One thing I've noticed in the log is this: ... *Mode: 118 (1024x768) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 ... DirectColorModeInfo: 0 PhysBasePtr: 0x0 Mode: 117 (1024x768) ... What does the X server do when that PhysBasePtr is zero ? Why is it zero and not 0xf000 ? Google seems to say that you need to ask for the linear mode to get the specs for it but the int(10,4f01) table looks like it doesn't need to change. The kernel seems to do it that way, it looks like X asks for the specs to paged mode, but it's very confused, does it? This is what vesafb says ... vesafb: framebuffer at 0xf000, mapped to 0xe088, using 6144k, total 32768k vesafb: mode is 1024x768x32, linelength=4096, pages=9 vesafb: protected mode interface info at c000:85ba vesafb: pmi: set display start = c00c85e9, set palette = c00c8652 vesafb: scrolling: redraw vesafb: Truecolor: size=0:8:8:8, shift=0:16:8:0 fb0: VESA VGA frame buffer device I am reminded about how these BIOSs have probably been tested, and with which (single) driver, that driver just tries the mode and if the user doesn't respond in a few seconds switches back to one that was working. So shouldn't the vesa driver use the same sequence of calls it does, with the mode sniffing of course but also an I don't care what you smell, just jump option too. So how easy would a 'paranoid but under orders mode' be :-) Anyway in the short term that machine is back on stable using the slow X vesa driver and mplayer -vo svga for fullscreen video. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404885: xserver-xorg-video-vesa VERY SLOW
On Sun, 29 Apr 2007, Brice Goglin wrote: Hi Robert, A couple months ago, you reported a bug to the Debian BTS regarding the X server being very slow with the vesa driver. Does this problem still happen today? There has not been many changes upstream in the vesa For stable and testing ... xserver-xorg: 1:7.1.0-18 xserver-xorg-video-vesa: 1:1.3.0-1 Kernel: Linux version 2.6.18-4-686 (Debian 2.6.18.dfsg.1-12) ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Mon Mar 26 17:17:36 UTC 2007 -- xorg (II) VESA(0): VESA VBE OEM Vendor: TRIDENT MICROSYSTEMS INC. (II) VESA(0): VESA VBE OEM Product: CYBER 2100 (II) VESA(0): VESA VBE OEM Product Rev: RXT 7.3 (16.28) (II) VESA(0): virtual address = 0xb7b3b000, physical address = 0xa, size = 65536 (==) VESA(0): Default visual is TrueColor (==) VESA(0): Backing store disabled -- mplayer VO: [x11] 480x352 = 480x352 Planar YV12 [zoom] SwScaler: using unscaled yuv420p - rgb32 special converter -- top PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 3095 root 5 -10 30044 22m 6064 S 46.9 4.4 1:13.40 Xorg 4166 robert15 0 50444 22m 15m S 2.7 4.4 0:05.50 mplayer The problem still exists in testing. For unstable ... The following packages will be REMOVED tzdata util-linux util-linux-locales The following packages will be upgraded: libc6 libc6-dev libdrm-dev libdrm2 locales xserver-xorg xserver-xorg-core WARNING: The following essential packages will be removed. This should NOT be done unless you know exactly what you are doing! util-linux tzdata (due to util-linux) so I really don't want to try to upgrade to unstable right now :-) Still I _think_ the problem is in the vesa driver itself which is the same version across all of stable, testing and unstable. However, I will try again next week. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389433: Probable fix for fbdev shadow framebuffer issues
That's bug #338241. I'm pondering changing the fbdev driver to default to 32bpp though. Well I suppose 32bpp is more likely with modern hardware. Still even if you can't easily get fb_var_screeninfo.bits_per_pixel as your default a big fat warning that they don't match and how to fix it would be in order IMO. I noticed that, but it's more likely a bug in vesafb. As the log indicates, the fbdev driver actually queries the framebuffer device on the usability of each mode. I've had a look at the kernel code ... Well it seems that the vesafb doesn't have an fb_check_var function to call so the FBIOPUT_VSCREENINFO ioctl is defined by fbmem.c to be the same as FBIOGET_VSCREENINFO. This is actually reasonable, it's trying to tell you the closest mode to the one you asked for. But X will have to check that the mode it gets back is the same as the one it asked for and reject it if not. (Especially if the returned mode is SMALLER than the request!) Most of the kernel fb drivers seem to be reasonably lax in what they accept as a mode request (those that can change the mode) and so I think this will definitly be a working as designed for the kernel. Also the TEST function doesn't look like it's implemented properly in all the drivers; I'd make sure you 'GET' the original setup and 'TEST' it after you've tested all your configured modes! ... But back to the beginning; the bug this report was opened for looks fixed to me. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403975: Upgrade report, continues
Segfault appear to be fixed by upgrade to vesa driver that's arrived in test today. However, the vesa driver is VERY slow compared to the trident driver when using mplayer even though I've disabled XVideo in the trident driver (mplayer window is blue when enabled). The Trident driver also claims the display has 8192 kByte of memory, it actually has 32768 kBytes. (It ignores a VideoRam option) The ShadowFB makes little difference to the vesa driver (for video) but prevents the trident driver working if it's set to yes; the screen remains in what appears to be a corrupted textmode. Note, however, this is NOT actually textmode as I have a vga=0x318 in my lilo.conf. I've also now tried the fbdev driver; it appears to be getting the video planes wrong in some way, I get four distorted copies of the desktop across the screen. (ppmtofb works fine; once package problem is overridden) # fbsev -i mode 1024x768-76 # D: 78.653 MHz, H: 59.949 kHz, V: 75.694 Hz geometry 1024 768 1024 768 32 timings 12714 128 32 16 4 128 4 rgba 8/16,8/8,8/0,0/0 endmode Frame buffer device information: Name: VESA VGA Address : 0xf000 Size: 6291456 Type: PACKED PIXELS Visual : TRUECOLOR XPanStep: 0 YPanStep: 0 YWrapStep : 0 LineLength : 4096 Accelerator : No # cat /proc/version Linux version 2.6.14-2-686 (Debian 2.6.14-6bpo1) ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #2 Fri Dec 30 03:19:34 CET 2005 # -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/# /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type man /etc/X11/xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Files FontPath/usr/share/fonts/X11/misc FontPath/usr/X11R6/lib/X11/fonts/misc FontPath/usr/share/fonts/X11/cyrillic FontPath/usr/X11R6/lib/X11/fonts/cyrillic FontPath/usr/share/fonts/X11/100dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/100dpi/:unscaled FontPath/usr/share/fonts/X11/75dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/75dpi/:unscaled FontPath/usr/share/fonts/X11/Type1 FontPath/usr/X11R6/lib/X11/fonts/Type1 FontPath/usr/share/fonts/X11/100dpi FontPath/usr/X11R6/lib/X11/fonts/100dpi FontPath/usr/share/fonts/X11/75dpi FontPath/usr/X11R6/lib/X11/fonts/75dpi # path to defoma fonts FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module Loadbitmap Loaddbe Loadddc Loaddri # Loadextmod Loadfreetype Loadglx Loadint10 Loadrecord Loadvbe # This disables XVideo SubSection extmod Option omit XVideo Option omit XVideo-MotionCompensation EndSubSection EndSection Section DRI Mode0666 EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc105 Option XkbLayout gb EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/psaux Option Protocol PS/2 Option Emulate3Buttons true EndSection Section InputDevice Identifier Synaptics Touchpad Driver synaptics Option SendCoreEventstrue Option Device/dev/psaux Option Protocol auto-dev Option HorizScrollDelta 0 EndSection Section Device Identifier Trident Microsystems CyberBlade XP4m32 Driver trident BusID PCI:1:0:0 Option CyberStretch yes #Option ShadowFB yes #Option VideoRam 32768 EndSection Section Device Identifier VMVware device Driver vmware EndSection Section Device Identifier VESA device Driver vesa
Bug#389433: Stage 1
Section Screen Identifier FB Device FB device Monitor LCD DefaultDepth24 DefaultFbBpp32 SubSection Display Depth 24 FbBpp 32 Modes 1024x768 EndSubSection EndSection If I add the FbBbp and DefaultFbBpp to xorg.conf or set the -fbbpp 32 command line option the display becomes readable. BUT rotation does NOT work, it appears that the shadowFB is not actually being used. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403975: Upgrade report
Package: x11-common Version: 1:7.1.0-8 Upgrade report from sarge. Packages removed for x11-common to be able to install: ucbmpeg-play qvwm opera-static The existing xorg.conf was very complex; it caused the Xserver to segfault. I have attached it but am not currently using it; I will probably be re-adding may of the changes if I find a specific problem I will add it here. I regenerated a new xorg.conf accepting the defaults (except for the display name and acceptable video modes). The machine this is on is a Toshiba Portage R100. Value in XkbLayout of generated xorg.conf file was uk the correct value is gb. With uk the keyboard was in us layout and the Ctrl-Alt Fkeys did not work. The default layout also used the synaptics driver for the 'touch-pad' mouse, I understand the device is an 'ALPS Glidepad'. This is sufficiently different from a synaptics for the default setup of the synaptics driver to be unusable and the documentation is not sufficient to correct this without a LOT of guesswork. I have disabled the synaptics driver and am using the default ps/2 setup. The known bugs in the xv extension and the DPMS are still present. 01:00.0 VGA compatible controller: Trident Microsystems CyberBlade XP4m32 (rev 91) -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/# XF86Config-4 (XFree86 X server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type man XF86Config-4 at the shell prompt.) # # This file is automatically updated on xserver-xfree86 package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xfree86 # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom # md5sum /etc/X11/XF86Config-4 /var/lib/xfree86/XF86Config-4.md5sum # dpkg-reconfigure xserver-xfree86 Section ServerFlags # OptionHandleSpecialKeys Always # OptionXkbDisable Option VTSysReq on # OptionVTSysreqToggle # OptionDontVTSwitch EndSection Section Files FontPathunix/:7100# local font server FontPathunix/:7110# local font server # if the local font server has problems, we can fall back on these FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/CID FontPath/usr/lib/X11/fonts/Speedo FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/cyrillic FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi EndSection Section Module Loadbitmap Loaddbe Loadddc Loaddri Loadfreetype Loadglx Loadint10 Loadrecord Loadtype1 # Load xtrap Loadvbe # Load GLcore # Not xorg # Load speedo # Not xorg Loadextmod # This disables XVideo # SubSection extmod # Option omit XVideo # Option omit XVideo-MotionCompensation # EndSubSection EndSection ### Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc105 Option XkbLayout gb #Option XkbOptionscompose:ralt Option XkbOptionscompose:caps #Option XkbOptionscaps:shift #Option XkbOptionssrvrkeys:none # No Ctrl-Alt-F1 #Option XkbRules xorg #Option XkbModel pc104 #Option XkbLayout us EndSection Section InputDevice Identifier PS Mouse Driver mouse Option CorePointer Option Device/dev/psaux Option Buttons 2 Option Protocol auto Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier GPM Mouse Driver mouse Option CorePointer Option Device/dev/gpmdata Option Buttons 2 Option Protocol MouseSystems Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section
Bug#256718: x-window-system package forces xserver-xfree86
Package: x-window-system Version: 4.3.0.dfsg.1-4 I have no hardware available for any xserver-xfree86 and I want to use vncserver. vncserver provides an 'xserver' but this isn't enough for x-window-system (via x-window-system-core). vncserver is based in xfree86 but it isn't a direct part of the project AIUI -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.cix.co.uk/~mayday
