Monitor doesn't display anything. EDID trouble ?
Hi, I know it may be off-topic, but the experience is there. I've just bought a used 30 monitor (HP ZR30w), and it doesn't display anything, even at BIOS time. The backlight is on, but I see nothing except a faint flickering at mode change times. Screen blanking works (the backlight switches off). I'm using a Radeon HD 5700 via DVI, debian/sid with kernel 3.1.0-rc7, Xorg 2:1.11.1.901-2 and radeon 1:6.14.2-2. After googling a bit, some people talk about a possible EDID problem (apparently it's possible to have the EDID somehow erased from the EEPROM ?). But Xorg.0.log does seem indicate that there's an EDID: [21.829] (II) RADEON(0): Monitor name: HP ZR30w [21.829] (II) RADEON(0): Serial No: CN4048041Z [21.829] (II) RADEON(0): EDID (in hex): [21.829] (II) RADEON(0):000022f06e2801010101 [21.829] (II) RADEON(0):3014010380402878ea8d85ad4f35b125 [21.829] (II) RADEON(0):0e50540001010101010101010101 [21.829] (II) RADEON(0):010101010101e26800a0a0402e603020 [21.829] (II) RADEON(0):36008190211abc1b00a050201730 [21.829] (II) RADEON(0):302036008190211a00fc0048 [21.829] (II) RADEON(0):50205a523330770a2020202000ff [21.829] (II) RADEON(0):00434e343034383034315a0a20200066 [21.829] (II) RADEON(0): Printing probed modes for output DVI-0 [21.829] (II) RADEON(0): Modeline 2560x1600x60.0 268.50 2560 2608 2640 2720 1600 1603 1609 1646 +hsync -vsync (98.7 kHz) [21.829] (II) RADEON(0): Modeline 1280x800x59.9 71.00 1280 1328 1360 1440 800 803 809 823 +hsync -vsync (49.3 kHz) ... and then: [21.854] (II) RADEON(0): Output DVI-0 using initial mode 2560x1600 Does anyone have an idea how I could pinpoint the problem ? Thanks a lot, Xav dmesg | grep drm [0.998537] [drm] Initialized drm 1.1.0 20060810 [1.009248] [drm] radeon kernel modesetting enabled. [1.009276] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver [1.009877] [drm] initializing kernel modesetting (JUNIPER 0x1002:0x68B8 0x1682:0x2994). [1.009914] [drm] register mmio base: 0xFE7C [1.009915] [drm] register mmio size: 131072 [1.010062] [drm] Detected VRAM RAM=1024M, BAR=256M [1.010064] [drm] RAM width 128bits DDR [1.010128] [drm] radeon: 1024M of VRAM memory ready [1.010130] [drm] radeon: 512M of GTT memory ready. [1.010139] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [1.010140] [drm] Driver supports precise vblank timestamp query. [1.010189] [drm] radeon: irq initialized. [1.010192] [drm] GART: num cpu pages 131072, num gpu pages 131072 [1.010720] [drm] Loading JUNIPER Microcode [1.034007] [drm] ring test succeeded in 1 usecs [1.034086] [drm] radeon: ib pool ready. [1.034146] [drm] ib test succeeded in 0 usecs [1.034517] [drm] Radeon Display Connectors [1.034518] [drm] Connector 0: [1.034519] [drm] DisplayPort [1.034520] [drm] HPD4 [1.034521] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [1.034523] [drm] Encoders: [1.034524] [drm] DFP1: INTERNAL_UNIPHY2 [1.034525] [drm] Connector 1: [1.034526] [drm] DVI-I [1.034527] [drm] HPD1 [1.034528] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [1.034529] [drm] Encoders: [1.034530] [drm] DFP2: INTERNAL_UNIPHY1 [1.034531] [drm] CRT2: INTERNAL_KLDSCP_DAC2 [1.034533] [drm] Connector 2: [1.034533] [drm] DVI-I [1.034534] [drm] HPD6 [1.034536] [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c [1.034537] [drm] Encoders: [1.034538] [drm] DFP3: INTERNAL_UNIPHY [1.034539] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [1.512032] [drm] Radeon display connector DP-1: No monitor connected or invalid EDID [1.563505] [drm] Radeon display connector DVI-I-1: Found valid EDID [1.573120] [drm] Radeon display connector DVI-I-2: No monitor connected or invalid EDID [1.573135] [drm] Internal thermal controller with fan control [1.573174] [drm] radeon: power management initialized [1.665202] [drm] fb mappable at 0xD0141000 [1.665203] [drm] vram apper at 0xD000 [1.665204] [drm] size 16384000 [1.665205] [drm] fb depth is 24 [1.665206] [drm]pitch is 10240 [1.665288] fbcon: radeondrmfb (fb0) is primary device [2.124952] fb0: radeondrmfb frame buffer device [2.124954] drm: registered panic notifier [2.124962] [drm] Initialized radeon 2.11.0 20080528 for :01:00.0 on minor 0 Xorg.0.log: [20.636] X.Org X Server 1.11.1.901 (1.11.2 RC 1) Release Date: 2011-10-14 [20.636] X Protocol Version 11, Revision 0 [20.636] Build Operating System: Linux 3.1.0-rc4-amd64 x86_64 Debian [20.636] Current Operating System: Linux bip 3.1.0-rc7-amd64 #1 SMP Mon Sep 26 13:09:27 UTC 2011 x86_64 [20.636] Kernel command line:
Re: Monitor doesn't display anything. EDID trouble ?
Le lundi 24 octobre 2011 à 16:53 -0400, Alex Deucher a écrit : On Mon, Oct 24, 2011 at 4:49 PM, Xavier Bestel xavier.bes...@free.fr wrote: Le lundi 24 octobre 2011 à 15:16 -0400, Alex Deucher a écrit : On Mon, Oct 24, 2011 at 3:01 PM, Xavier Bestel xavier.bes...@free.fr wrote: Hi, I know it may be off-topic, but the experience is there. I've just bought a used 30 monitor (HP ZR30w), and it doesn't display anything, even at BIOS time. The backlight is on, but I see nothing except a faint flickering at mode change times. Screen blanking works (the backlight switches off). I'm using a Radeon HD 5700 via DVI, debian/sid with kernel 3.1.0-rc7, Xorg 2:1.11.1.901-2 and radeon 1:6.14.2-2. After googling a bit, some people talk about a possible EDID problem (apparently it's possible to have the EDID somehow erased from the EEPROM ?). But Xorg.0.log does seem indicate that there's an EDID: [21.829] (II) RADEON(0): Monitor name: HP ZR30w [21.829] (II) RADEON(0): Serial No: CN4048041Z [21.829] (II) RADEON(0): EDID (in hex): [21.829] (II) RADEON(0):000022f06e2801010101 [21.829] (II) RADEON(0):3014010380402878ea8d85ad4f35b125 [21.829] (II) RADEON(0):0e50540001010101010101010101 [21.829] (II) RADEON(0):010101010101e26800a0a0402e603020 [21.829] (II) RADEON(0):36008190211abc1b00a050201730 [21.829] (II) RADEON(0):302036008190211a00fc0048 [21.829] (II) RADEON(0):50205a523330770a2020202000ff [21.829] (II) RADEON(0):00434e343034383034315a0a20200066 [21.829] (II) RADEON(0): Printing probed modes for output DVI-0 [21.829] (II) RADEON(0): Modeline 2560x1600x60.0 268.50 2560 2608 2640 2720 1600 1603 1609 1646 +hsync -vsync (98.7 kHz) [21.829] (II) RADEON(0): Modeline 1280x800x59.9 71.00 1280 1328 1360 1440 800 803 809 823 +hsync -vsync (49.3 kHz) ... and then: [21.854] (II) RADEON(0): Output DVI-0 using initial mode 2560x1600 Does anyone have an idea how I could pinpoint the problem ? The EDID looks ok to me. Do any other modes work? Try 1280x800. Try the other DVI port. If the neither port lights up the monitor (especially if the bios produces no display), it's probably a bad monitor. OK, thanks to you I've found the problems: 1) this monitor is apparently unable to display anything but 1280x800 or 2560x1600, so no BIOS nor GRUB for me. You should still get a BIOS image. The vbios takes the preferred mode from the monitor's EDID and uses the scaler to fake the legacy modes. It's probably trying to use 2560x1600 mode which requires a dual link cable. OK, I'll see that with the good cable. Thanks Alex, Xav ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: clip masks/simulating transparency
On Tue, 2011-05-31 at 15:28 +1000, Amy C wrote: Can anyone think of an alternative way to do this (have the penguins walk over a screen of my choosing and restore said window after they've passed through, without too much flickering? You should use compositing of an ARGB pixmap. It will only work with a compositor but nowadays all desktop use one (Compiz/Unity, Mutter/GnomeShell, Kwin). Compositing is implemented much more efficiently than windows shaping. Xav ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: clip masks/simulating transparency
On Tue, 2011-05-31 at 09:58 +0200, Xavier Bestel wrote: On Tue, 2011-05-31 at 15:28 +1000, Amy C wrote: Can anyone think of an alternative way to do this (have the penguins walk over a screen of my choosing and restore said window after they've passed through, without too much flickering? You should use compositing of an ARGB pixmap. It will only work with a compositor but nowadays all desktop use one (Compiz/Unity, Mutter/GnomeShell, Kwin). Compositing is implemented much more efficiently than windows shaping. My bad, I looked at the source, it doesn't use shaped windows. Still, using composited windows per pinguin may be a win. Xav ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Custom font format
Hi, On Mon, 2011-01-10 at 12:59 +0100, Michael Thalmeier wrote: Hi ! We are currently developing an application that is using xlib directly for all the drawing operations. Our problem is, that we have a huge library of fonts in a custom font format, that is currently not supported by the x server. Does anybody know what would be the best way to deal with such custom font formats ? Nowadays the winning strategy seems to be to handle all text client-side and blit it on screen using XRender. So either you convert your fonts to an existing format (OpenType even handles bitmap fonts), or you do your own font drawing routines. You could think of extending Freetype2 to handle your format, but you'll have to maintain your code on your own, and I don't think it's a trivial task. HTH, Xav ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Which one to buy ?
On Sun, 2010-11-14 at 02:21 +0100, Steffen Schaumburg wrote: Here comes that time again: I have to buy a graphic card, I want to buy a radeon, not too long/wide (limited space in the box), reasonably recent and powerful, to be used in a debian/sid system. What do I buy if I want 3D (compiz at least) now, or at least very soon ? I guess if AMD pours money on linux support, it's because they want their stuff to be bought. But it's not clear yet when the latest gen is usable without fglrx. I don't know how much you intend to game, but I would recommend a Radeon-HD 5750 (basically a half 5850). The series won't be replaced by a 67xx series (as far as it looks for now) and are for the power they offer quite cheap. Open driver support Xrender and OpenGL quite ok. - Clemens For gaming a mid-range card like the suggested is a good choice IMHO, tho' I'm no longer carefully following the field. If you do not intend to play very recent demanding games on high settings even a low-end card (or chipset-based GPU) should be sufficient - with the huge advantage that they don't need active cooling. One note of caution, using a HD5xxx or higher chip does currently require -git stuff to get even Compiz afaik, unless you're willing to (temporarily) use fglrx. HD4xxx and lower (e.g. I have a chipset-HD3xxx) work great with released kernels and free drivers, tho I don't know if sid contains sufficiently recent versions. Ok, thanks to everyone who answered. I'll settled on a 5770 (I've found there exists a single-slot version), which looks like a good compromise (for me) between GPU power, driver readiness, and size. Thanks again for the info ! Xav ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: radeon driver EXA option
Le vendredi 01 octobre 2010 à 08:48 -0700, ott0disk a écrit : Hi everybody,i'm having some trouble with the xorg.conf configuration file,i recently switched from the amd/ati proprietary driver to the radeon that support well my graphic card. You should try just getting rid of your xorg.conf. Xav ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
WebGL under debian, radeon driver
Hi, I'm using a debian system rather uptodate, with: xserver-xorg-video-ati 1:6.13.1-2 libgl1-mesa-dri 7.8.2-2 libdrm2 2.4.21-2 and I'm trying to get various WebGL examples working under Firefox 4b7 and Chromium 6.0.472.62. Lot of them don't work, and the ones that do are quite slow. E.g: http://scenejs.org/dist/curr/extr/examples/hello-teapot/index.html looks like 2 fps on my machine, which has a q9...@3.00ghz + RV630. Is that how it's supposed to be, or is there something not well configured on my machine ? Thanks, Xav ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: WebGL under debian, radeon driver
Le samedi 02 octobre 2010 à 19:22 +0200, Sven Arvidsson a écrit : On Sat, 2010-10-02 at 19:11 +0200, Xavier Bestel wrote: I'm using a debian system rather uptodate, with: xserver-xorg-video-ati 1:6.13.1-2 libgl1-mesa-dri 7.8.2-2 libdrm2 2.4.21-2 and I'm trying to get various WebGL examples working under Firefox 4b7 and Chromium 6.0.472.62. Lot of them don't work, and the ones that do are quite slow. E.g: http://scenejs.org/dist/curr/extr/examples/hello-teapot/index.html looks like 2 fps on my machine, which has a q9...@3.00ghz + RV630. Is that how it's supposed to be, or is there something not well configured on my machine ? Sounds like you're only getting software rendering? I've had it working (accelerated) with both Chrome and Firefox, but I haven't tried it with r600 hardware yet. Yes, I'm pretty sure. Compiz is accelerated, and so is Google Earth. Glxinfo says also so. How many fps do you reach ? I think you still need an Xserver with pbuffer support (the one in debian experimental should do) and you're probably better off with really recent 3D driver - the 7.9 RC or straight from git. Xserver from experimental is uninstallable here (deps problem). Thanks, Xav ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Exclusive Fullscreen Mode
On Mon, 2010-09-06 at 17:53 +0200, Roland Plüss wrote: I tried searching on the Internet for informations on how to take over the screen using Xlib. I think here about fullscreen exclusive access like for example SDLMAME does it. I stumbled so far though only on one single mentioning of an Xlib call which should allow switching a window into a FullscreenExclusiveMode. I could though find nothing about such a call nor this FullscreenExclusiveMode. Has anybody an idea what this FullscreenExclusiveMode could be or in general how one can make a window take over the entire screen? Can't you just look at SDL's source code ? Xav ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Howto Lower brightness on Apple LCD Monitor? KUbuntu 10.4, KDE System Settings Display; jor XOrg
On Wed, 2010-06-23 at 00:41 +0200, Éric Piel wrote: Op 22-06-10 23:56, giovanni_re schreef: Didn't get an answer on KUbuntu list, so hopefully someone here might have a suggestion. == I've just installed an Apple Cinema Display (LCD) monitor. This is a 5 year old monitor. Using KUbuntu 10.4 The apple website indicates this monitor has: User controls (hardware and software): Display power, system sleep, system wake, brightness and display tilt http://support.apple.com/kb/SP79 http://support.apple.com/kb/SP77 Brightness is what I want to turn down. Looking in the KDE System Settings General Computer Administration Display Size orientation DVI-0 there is no adjustment for brightness. Anyone know how to decrease brightness on this? What sw manages the KDE system settings for Displays? KDE? X? Is there a way to turn down the brightness using some X config? Is there a GUI for doing X configuration settings? Why do you think you can change the brightness via software? It is very unsual for separate monitors to support this. Isn't there some buttons on the monitor to do that?! Anyway, if you really want to do this by software: * DDC/CI is the key. Try using ddccontrol. But your graphic card must support it, and your monitor too. In practice, it's unlikely to work. Well, it works quite well on my Dell 24 (radeon driver), even if it has front controls. I think more monitors support this than you think. The problems are: - KMS/Xorg don't support it, so you have to be root for ddccontrol to work. - Controls aren't standardized, so you have to play with the 255 possible controls to find the useful ones (e.g. brightness and color temp). Xav ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-video-ati 6.13.0
Hi, On Mon, 2010-04-05 at 12:18 -0400, Alex Deucher wrote: Major changes since the 6.12.x series - Add support for KMS (kernel modesetting) for r1xx-evergreen asics I think you meant r8xx-evergreen here. Xav ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: The current dualseat status for radeon?
On Mon, 2010-01-04 at 16:24 +0200, Marius Gedminas wrote: On Sat, Jan 02, 2010 at 01:26:14PM +, Kārlis Repsons wrote: I wonder, what is the current status for dualseat setup with radeon cards? Are there any people out there by now, who have it all working just fine? I could add, that with nvidia I had dead screens upon resume along with all sorts of experiments to make it work. Well, but the idea failed just over hibernation problem some year ago. So is it worth buying two new radeon cards, as nvidia is a real pain with its blob and I have an impression that with radeon things would be better (certainly correct me if not)...? Why buy two? New Radeon cards support up to 6 monitors from a single card (2 DVI-I, 1 HDMI, 1 DisplayPort). (Then again new Radeon cards aren't exactly what you would call well-supported under Linux, at least if you only consider free drivers...) Even r600 aren't supported by current distros (except as glorified framebuffers), so I guess if you want something working now (as in not in a year or so), try buying some used r500 on ebay instead. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client side ddc/ci
On Wed, 2009-12-02 at 20:59 +1100, Graeme Gill wrote: Kai-Uwe Behrmann wrote: ddccontrol uses /dev/i2c-xxx, so the problem of non root access remains with that library. Otherwise it seems very fine. Is there a mechanism to associate the /dev/i2c-xxx with the matching display though ? The X server already kind of does that when it gets EDID by DDC. One more argument for X server (by way of KMS I think) integration. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: CT ct65545 problem
On Mon, 2009-10-26 at 18:15 +0100, walter harms wrote: recently versions of the server don't support ISA anymore. the the error message should be more clear: if Primary Device is == ISA ISA is not supported anymore (since 1.x) If the server doesn't support ISA, it will have a hard time knowing that Primary Device is == ISA ... Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X ports?
Le lundi 28 septembre 2009 à 12:23 -0500, Busse Rich - rbusse a écrit : Hi, Does the X protocol use specific IP ports? We have been running X in a trusted network situation but now also need to use X in a WAN / VPN situation. If there are special ports for X, I'll need to have the firewall guys open them. Having X ports open to the wild exterior is not recommended. The security isn't up to todays standards. You'd better try ssh X proxy, with ssh -Y. That being said, IIRC X11 ports start at 6000 (add the display number). Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: proportional panning
On Tue, 2009-06-09 at 16:44 +0900, Miles Bader wrote: Xavier Bestel xavier.bes...@free.fr writes: Why not making the proportional mode simply replace the push mode ? Why keeping an allegedly inferior panning mode ? Don't. Some people are used to this behavior. Ok, I was under the impression that the panning code for RandR 1.3 was quite new. But I forgot about the old Virtual thing. Also, which behavior is better seems rather subjective. For having tried both of them, the proportional panning is quite pleasant (it looks a lot like the Compiz enhanced zoom). Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: proportional panning
On Mon, 2009-06-08 at 18:16 +0200, Matthias Hopf wrote: On Jun 08, 09 17:55:20 +0200, Xavier Bestel wrote: Why not making the proportional mode simply replace the push mode ? Why keeping an allegedly inferior panning mode ? Don't. Some people are used to this behavior. Ok, I was under the impression that the panning code for RandR 1.3 was quite new. But I forgot about the old Virtual thing. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
On Tue, 2009-05-26 at 11:50 +1000, Peter Hutterer wrote: The main benefit of a grab in the use of menus is that you will get the next event regardless of where it occurs. This is what makes the menu disappear when you click elsewhere. If the application didn't grab, the menu could only disappear by activating a menu item, or - assuming the application supports this - by clicking elsewhere in one of the application's windows. Just as a datapoint, AFAIK that's how Windows GUI toolkits work. They don't grab the whole display, thay just wait for events in their window. Any suggestions on solving this feature through other means is appreciated (note that registering for events on every visible window doesn't count). Limiting events to the application windows doesn't seem that bad. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Thu, 2009-04-09 at 10:29 -0400, Jim Gettys wrote: Someday somehow I'll try to do some tests to check whether that's really true with a better optimized protocol, because right now everything that uses xft over a ssh tunnel is an horrible pain in the ass, I don't know what problem you are seeing. Over ssh in particular, with compression (-C), performance is much, much better with client side fonts than it ever was with server side fonts. I'd hate to sound as trollish as some in this thread, but there I have to agree with Olivier: GTK2 apps are unusable over an ssh -C -Y tunnel whereas core-fonts apps are. I dunno exactly why, but I remember distinctly when client-side fonts were switchable in GTK, and the perf hit over ssh (over an ADSL link) was big. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Thu, 2009-04-09 at 12:46 -0400, Jim Gettys wrote: On Thu, 2009-04-09 at 18:29 +0200, Xavier Bestel wrote: On Thu, 2009-04-09 at 10:29 -0400, Jim Gettys wrote: Someday somehow I'll try to do some tests to check whether that's really true with a better optimized protocol, because right now everything that uses xft over a ssh tunnel is an horrible pain in the ass, I don't know what problem you are seeing. Over ssh in particular, with compression (-C), performance is much, much better with client side fonts than it ever was with server side fonts. I'd hate to sound as trollish as some in this thread, but there I have to agree with Olivier: GTK2 apps are unusable over an ssh -C -Y tunnel whereas core-fonts apps are. I dunno exactly why, but I remember distinctly when client-side fonts were switchable in GTK, and the perf hit over ssh (over an ADSL link) was big. That is downright strange. Are you comparing the same application? or different applications? GTK may be doing something really stupid internally, that has nothing to do with fonts, but is related to the latency. I've suspected as much at times Please be so kind as to give us a concrete test case I'm afraid I can't anymore, I don't have the handy GTK1 apps which could be switched to code-fonts or Xft. However I just tried gnome-terminal (with no menubar, scrollbar nor any other widget) and xterm in parallel over a slow ssh link, and I was wrong: gnome-terminal here feels snappier than xterm ! So I stand by my assertion that GTK2 apps are slower (I use them often over the slow ssh link and it's a pain), but I retract the explanation. You're right, they must do something stupid somewhere. If gnome-terminal can be snappy (or even not too sluggish in fullscreen), so should all the others. Sorry for the noise (really), Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: r200 exa performance regression in xserver-1.6?
Hi, On Thu, 2009-03-26 at 16:05 +1000, Dave Airlie wrote: Try Option AccelDFS true Any reason this kind of option isn't the default ? It seems xorg.conf is mandatory for radeons just for the don't suck true options. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: r200 exa performance regression in xserver-1.6?
On Thu, 2009-03-26 at 20:29 +1000, Dave Airlie wrote: On Thu, Mar 26, 2009 at 7:11 PM, Xavier Bestel xavier.bes...@free.fr wrote: Hi, On Thu, 2009-03-26 at 16:05 +1000, Dave Airlie wrote: Try Option AccelDFS true Any reason this kind of option isn't the default ? It seems xorg.conf is mandatory for radeons just for the don't suck true options. Its the default on PCI and PCIE systems, however it can make AGP system unreliable due to AGP being badly designed heap of crap. That's pretty clear. So on AGP people get to do it themselves. Thanks for the explanation. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: New Video Decode and Presentation API
Le vendredi 27 février 2009 à 15:21 -0800, Andy Ritger a écrit : Neither, I'm trying to not use deinterlacing in the graphics card. Is it technically (theoretically) possible to rearrange the order of merging the fields and scaling? I think if you want to scale, then you really need to deinterlace, first. Not if you want to scale to an interlaced display. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [EDIT] Why do I need mouse acceleration to move windows and click buttons?
On Thu, 2009-02-26 at 18:58 +0100, Dirk wrote: People who believe they need an accelerated pointer to click buttons or move windows are not bright enough to realize the absence of acceleration anyways. Sorry for not being bright enough for you, but I do enjoy acceleration. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Input transformations: Compiz
Hi, On Wed, 2009-01-21 at 13:01 +0900, Joel Bosveld wrote: After hiding the cursor once with XFixes, some mouse cursors will simply be invisible. The Firefox loading cursor being one of them. Woah, this thing has been driving me mad for a long time, and I couldn't find an explanation. Thanks for this ! Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Font rendering problem in 1.6 branch (fine in 1.5 and master)
Le vendredi 16 janvier 2009 à 14:22 -0800, Jeremy Huddleston a écrit : Has anyone noticed oddities in font rendering (or perhaps even just font selection) in the 1.6 branch? It looks fine in 1.5 and in master, but 1.6 shows something different. I looked through the list of nominated patches for 1.6 and nothing jumped out as fixing this. Does someone have a patch they want to nominate that addresses this issue, or do I need to go digging to find it... Are you sure it's not just the DPI which is different ? Maybe you should compare logfiles or xdpyinfo outputs. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Increasing the frame buffer size
On Tue, 2009-01-06 at 09:10 -0800, Dirk Hohndel wrote: On Tue, 06 Jan 2009 18:01:21 +0100 Xavier Bestel xavier.bes...@free.fr wrote: You can add a directive in your Xorg config file: Virtual 1920 1200 so that the maximum screen size is correct for you. This used to have to go into the Display SubSection. Which is where I am struggling. I can't seem to create a config file that keeps the nice flexibility of having no config file (let the server figure everything out) and still allows me to have a Display SubSection... Once I have that, I seem to need a screen section which requires a Device section and a Monitor section and... it turns very inflexible. Any way around that? Not that I know of, sadly. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Signal 11 in xorg-server
Hi, On Wed, 2008-12-03 at 12:30 +0300, Руслан Бондарь wrote: Hello all. Sometimes my xorg server crashes. Xorg-server version: 1.5.2 Linux distro: gentoo X11 wm: openbox-3.4.7.2 I notice this problem only when I'm using dual-screen configuration. I have dual headed nVidia GeForce 8600 with proprietary driver. If you can't reproduce the crash with the free nv driver, you'll have to take that issue to the NVIDIA support. Thanks, Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On Mon, 2008-12-01 at 11:10 -0800, Alan Coopersmith wrote: Xavier Bestel wrote: On Mon, 2008-12-01 at 16:58 +0100, Nicolas Mailhot wrote: Le Lun 1 décembre 2008 16:47, Alexander E. Patrakov a écrit : Apriori, there is no sensible default keyboard layout. There could be if the hardware started advertising what actually painted on its keys (and even then many people would want to override it). Since it does not, you're right. I think it does. Some entries in the Microsoft support pages tend to say so, at least: http://support.microsoft.com/kb/280725 http://support.microsoft.com/kb/304614 The USB specs have layout as an optional field that most vendors don't fill in since it would cost a few cents extra per keyboard to put in dip switches or different PROMs for different layouts, instead of just attaching different keytops.Sun keyboards do, and I think Apple do, since auto-detection was worth the few extra cents for our users, but I don't know of any others that do. How sad. (And because Sun keyboards do, on Solaris, we've always had X ask the kernel for the keyboard layout, from either the hardware or the user settings, and use that to set the X keyboard layout. I've been working with our HAL team to have HAL do this as well as we're moving to Xorg 1.5, and it seems to be working for us, but it depends on the Solaris keyboard layout ioctls, so won't be generally useful, other than as proof that something better than us-for-everyone is possible.) Maybe Xorg should still try to use it if present, and output a tiny warning in the logs otherwise, to make people prefer the right kind of keyboard. Thanks, Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Sun, 2008-11-30 at 14:11 +, Beso wrote: just look at the evdev driver. i think that after its development the usability of keyboards and mouses has increased quite a lot. now i cannot see a reason to switch back to kbd + mouse instead of evdev. I see one: keyboard layout isn't recognized nor easily configured, so at login screen you're stuck with a qwerty keyboard. Otherwise it's perfect. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Mon, 2008-12-01 at 12:59 +, Alan Cox wrote: The result is that since there is no single shared layout X and the kernel use, no layout info is exposed by the kernel infrastructure. (and from a functional point of view there is no reason a key should have a different behaviour in X and the console). So load the correct keyboard tables. The kernel is not and never has been a keyboard layout manager. That is a policy item, and the fact you may want differing behaviour and policy for different systems means it needs to stay so. I don't think it does. Last time I tried, plugging both an azerty and a qwerty keyboard resulted in only one of them having the correct layout. Maybe something in evdev should somehow translate layouts before mixing events together. Or tag keys with a kind of keyboard-dependant cookie to make sense of them afterwards (I thnk there's an ID in the USB protocol for the keyboard layout, but it's not used right now). Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On Mon, 2008-12-01 at 16:58 +0100, Nicolas Mailhot wrote: Le Lun 1 décembre 2008 16:47, Alexander E. Patrakov a écrit : Apriori, there is no sensible default keyboard layout. There could be if the hardware started advertising what actually painted on its keys (and even then many people would want to override it). Since it does not, you're right. I think it does. Some entries in the Microsoft support pages tend to say so, at least: http://support.microsoft.com/kb/280725 http://support.microsoft.com/kb/304614 HTH, Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Rotate trouble on r300 (was: Re: XRandR rotate support HW rotate or not?)
On Thu, 2008-11-06 at 10:51 +0100, Michel Dänzer wrote: On Thu, 2008-11-06 at 10:39 +0100, Xavier Bestel wrote: On Thu, 2008-11-06 at 10:35 +0100, Michel Dänzer wrote: On Thu, 2008-11-06 at 10:30 +0100, Xavier Bestel wrote: On Thu, 2008-11-06 at 10:27 +0100, Michel Dänzer wrote: On Thu, 2008-11-06 at 10:20 +0100, Xavier Bestel wrote: [...] with page flipping disabled, the driver hangs regularly the machine. It's a solid lock, the machine doesn't pong. Is that only when using rotation, or even otherwise? Even otherwise. Still using compiz though? Then there seems to be a problem with non-flip buffer swaps, maybe in the radeon DRM kernel module. Yes, always using compiz. I'm using a relatively recent git checkout of the radeon driver, but all the rest is from debian packages (unstable + experimental when applicable). Does it also happen with the radeon kernel module built from git://anongit.freedesktop.org/git/mesa/drm ? So far so good. Thanks, Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Rotate trouble on r300 (was: Re: XRandR rotate support HW rotate or not?)
On Sat, 2008-11-01 at 12:25 +0100, Michel Dänzer wrote: On Fri, 2008-10-31 at 19:17 +0100, Xavier Bestel wrote: Le vendredi 31 octobre 2008 à 09:34 -0400, Alex Deucher a écrit : 2008/10/31 [EMAIL PROTECTED]: Dear Keith Packard： I have recently study RandR, I found if we use RandR rotate no matter static rotate or dynamic rotate，we always use RandR's own software rotate. We draw the screen desktop very slow, how can we support HW rotate using RandR or it is a RandR limitation, if it is, RandR1.3 has support HW rotate or not ? Your driver needs to implement the EXA composite hook with support for transforms and the randr 1.2 shadow_create/allocate/destroy hooks. The basic idea is that when you elect to rotate your screen, a shadow framebuffer is allocated in the randr core code calling the driver shadow* hooks to allocate a buffer for the rotated screen. The crtc is then pointed to this shadow buffer. The randr core code then uses the driver's EXA composite hook to transform the regions that are damaged and display them in the shadow buffer. Both the Intel driver and the radeon driver implement this. BTW, does anyone know why rotating the screen doesn't play well with compiz on an r300 ? The screen looks garbled (like if the framebuffer wasn't rotated so the pitch is all wrong), every second image (e.g. when you move the cube slowly, one image is perfect, the next one is garbled). Does disabling tiling and/or page flipping help? Ok, after using it for a while, I think I can say it doesn't help that much: with page flipping disabled, the driver hangs regularly the machine. It's a solid lock, the machine doesn't pong. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Rotate trouble on r300 (was: Re: XRandR rotate support HW rotate or not?)
Le samedi 01 novembre 2008 à 14:51 +0100, Xavier Bestel a écrit : Le samedi 01 novembre 2008 à 12:25 +0100, Michel Dänzer a écrit : On Fri, 2008-10-31 at 19:17 +0100, Xavier Bestel wrote: BTW, does anyone know why rotating the screen doesn't play well with compiz on an r300 ? The screen looks garbled (like if the framebuffer wasn't rotated so the pitch is all wrong), every second image (e.g. when you move the cube slowly, one image is perfect, the next one is garbled). Does disabling tiling and/or page flipping help? Disabling page flipping helps a lot, thank you ! Now it works perfectly well. I didn't try disabling tiling yet. Should I ? Oh, and here is the log with page flipping enabled. The only meaningful diffs I saw with page flipping disabled (apart that it works) are: -(**) RADEON(0): Option EnablePageFlip true +(**) RADEON(0): Option EnablePageFlip false -(**) RADEON(0): Page Flipping enabled +(**) RADEON(0): Page Flipping disabled -(II) RADEON(0): Damage tracking initialized for page flipping HTH, Xav X.Org X Server 1.5.2 Release Date: 10 October 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.26-1-686 i686 Debian Current Operating System: Linux bip 2.6.26-1-686 #1 SMP Sat Oct 18 16:22:25 UTC 2008 i686 Build Date: 11 October 2008 08:22:35PM xorg-server 2:1.5.2-1 ([EMAIL PROTECTED]) 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: Sat Nov 1 09:45:02 2008 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor default monitor (**) | |--Device ATI Radeon 9600XT (==) No monitor specified for screen Default Screen. Using a default monitor configuration. (**) |--Input Device Generic Keyboard (**) |--Input Device Generic Mouse (**) Option AllowDeactivateGrabs (==) Automatically adding devices (==) Automatically enabling devices (==) No FontPath specified. Using compiled-in default. (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 (==) ModulePath set to /usr/lib/xorg/modules (II) Open ACPI successful (/var/run/acpid.socket) (II) Loader magic: 0x81d04c0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 4.1 X.Org XInput driver : 2.1 X.Org Server Extension : 1.1 X.Org Font Renderer : 0.6 (II) Loader running on linux (++) using VT number 8 (--) PCI:*([EMAIL PROTECTED]:0:0) ATI Technologies Inc RV350 AR [Radeon 9600] rev 0, Mem @ 0xe000/0, 0xff8f/0, I/O @ 0xec00/0, BIOS @ 0x/131072 (--) PCI: ([EMAIL PROTECTED]:0:1) ATI Technologies Inc RV350 AR [Radeon 9600] (Secondary) rev 0, Mem @ 0xd000/0, 0xff8e/0 (II) System resource ranges: [0] -1 0 0x - 0x (0x1) MX[B] [1] -1 0 0x000f - 0x000f (0x1) MX[B] [2] -1 0 0x000c - 0x000e (0x3) MX[B] [3] -1 0 0x - 0x0009 (0xa) MX[B] [4] -1 0 0x - 0x (0x1) IX[B] [5] -1 0 0x - 0x (0x1) IX[B] (II) LoadModule: extmod (II) Loading /usr/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor=X.Org Foundation compiled for 1.5.2, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 1.1 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: dbe (II) Loading /usr/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor=X.Org Foundation compiled for 1.5.2, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 1.1 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: glx (II) Loading /usr/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor=X.Org Foundation compiled for 1.5.2, module version = 1.0.0 ABI class: X.Org Server Extension, version 1.1 (==) AIGLX enabled (==) Exporting typical set of GLX visuals (II) Loading extension GLX (II) LoadModule
Rotate trouble on r300 (was: Re: XRandR rotate support HW rotate or not?)
Le vendredi 31 octobre 2008 à 09:34 -0400, Alex Deucher a écrit : 2008/10/31 [EMAIL PROTECTED]: Dear Keith Packard： I have recently study RandR, I found if we use RandR rotate no matter static rotate or dynamic rotate，we always use RandR's own software rotate. We draw the screen desktop very slow, how can we support HW rotate using RandR or it is a RandR limitation, if it is, RandR1.3 has support HW rotate or not ? Your driver needs to implement the EXA composite hook with support for transforms and the randr 1.2 shadow_create/allocate/destroy hooks. The basic idea is that when you elect to rotate your screen, a shadow framebuffer is allocated in the randr core code calling the driver shadow* hooks to allocate a buffer for the rotated screen. The crtc is then pointed to this shadow buffer. The randr core code then uses the driver's EXA composite hook to transform the regions that are damaged and display them in the shadow buffer. Both the Intel driver and the radeon driver implement this. BTW, does anyone know why rotating the screen doesn't play well with compiz on an r300 ? The screen looks garbled (like if the framebuffer wasn't rotated so the pitch is all wrong), every second image (e.g. when you move the cube slowly, one image is perfect, the next one is garbled). Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
