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 wrote: > > Le lundi 24 octobre 2011 à 15:16 -0400, Alex Deucher a écrit : > >> On Mon, Oct 24, 2011 at 3:01 PM, Xavier Bestel > >> 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 "2560x1600"x60.0 268.50 2560 > >> > 2608 2640 2720 1600 1603 1609 1646 +hsync -vsync (98.7 kHz) > >> > [21.829] (II) RADEON(0): Modeline "1280x800"x59.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: Monitor doesn't display anything. EDID trouble ?
Le lundi 24 octobre 2011 à 15:16 -0400, Alex Deucher a écrit : > On Mon, Oct 24, 2011 at 3:01 PM, Xavier Bestel 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 "2560x1600"x60.0 268.50 2560 2608 > > 2640 2720 1600 1603 1609 1646 +hsync -vsync (98.7 kHz) > > [21.829] (II) RADEON(0): Modeline "1280x800"x59.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 problem 1) this monitor is apparently unable to display anything but 1280x800 or 2560x1600, so no BIOS nor GRUB for me. 2) my cable is single-link, so Xorg's default guess doesn't work. After hooking a second monitor, and choosing 1280x800 for the big one, everything's working (sort-of). I'll hunt for a dual-link or displayport cable, whichever is cheapest. Can Xorg detect if the cable is single-link ? 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: Monitor doesn't display anything. EDID trouble ?
Le lundi 24 octobre 2011 à 15:16 -0400, Alex Deucher a écrit : > On Mon, Oct 24, 2011 at 3:01 PM, Xavier Bestel 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 "2560x1600"x60.0 268.50 2560 2608 > > 2640 2720 1600 1603 1609 1646 +hsync -vsync (98.7 kHz) > > [21.829] (II) RADEON(0): Modeline "1280x800"x59.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. 2) my cable is single-link, so Xorg's default guess doesn't work. After hooking a second monitor, and choosing 1280x800 for the big one, everything's working (sort-of). I'll hunt for a dual-link or displayport cable, whichever is cheapest. Can Xorg/radeon detect that the DVI cable is single-link ? 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
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 "2560x1600"x60.0 268.50 2560 2608 2640 2720 1600 1603 1609 1646 +hsync -vsync (98.7 kHz) [21.829] (II) RADEON(0): Modeline "1280x800"x59.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: BOOT_IMAGE=/vmlinuz-3.1.0-rc7
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: 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: 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: Info about X-architecture
On Tue, 2010-10-05 at 10:16 +0100, Ross Burton wrote: > On Tue, 2010-10-05 at 11:45 +0530, vijay singh wrote: > > Main CPU : ARM11 > > Graphic Card : SGX535. > > You should speak to the vendor about getting the accelerated X drivers > for the SGX from Imagination. Yes, you are buying an accelerated 3D-capable (=>fast) graphics chip, but all you'll be able to use is a plain framebuffer (=>slow). 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
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: 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
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 10:20 -0800, Corbin Simpson wrote: > Fedora has accelerated r600. Sorry, I thought debian unstable was more up-to-date than other stable distros. Xav ___ xorg mailing list xorg@lists.freedesktop.org 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: client side ddc/ci
Hi, On Wed, 2009-12-02 at 19:07 +1000, Dave Airlie wrote: > > > > how would one talk with a monitor over DDC/CI on a user side, non root > > application. I would like to do monitor gamma curves I/O, EDID polling and > > other non standard communication. > > > > The /dev/i2c-xxx device nodes are root access only on my system. I can > > chmod them with o+rw, but thats shurely not the general solution. > > > > What is a good place to start with in Xorg? > > > > I have seen the ddc/XF64DDC.[h,c] and i2c/xf86i2c.[h,c] modules in the > > server. Is already one of those APIs exposed? > > > > As I understand, the root windows or xrandr output EDID atom is a one time > > thing and too static for my needs. > > > > You'd need to add protocol for the client side apps to talk to the X server,. > > you could possibly do this with xrandr properties or extending xrandr, > then drivers would have to talk to the i2c via X i2c or kernel i2c in kms > case. Have a look at http://ddccontrol.sourceforge.net/ for a working implementation that bypasses the X server (although as says Dave, going through Xrandr looks like the right thing to do). Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: C&T 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: Xlib: connection to "sr1-ubur-20:34.0" refused by server
Hi, On Fri, 2009-10-23 at 11:36 -0400, Ethan Mallove wrote: > Hello, > > It seems I suddenly can not access my own DISPLAY. All X applications > now error out with the following, e.g., > > $ xterm > Xlib: connection to "sr1-ubur-20:34.0" refused by server > Xlib: No protocol specified > xterm Xt error: Can't open display: sr1-ubur-20:34.0 try export DISPLAY=:0 Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How X works / lightest Window Manager
Hi, On Tue, 2009-09-29 at 12:28 -0300, Lucas Mocellin wrote: > ah, and I will use firefox. the page that firefox will open is a > Moodle (moodle.org) and there are multimedia stuff (audio, videos, > flash) > > On Tue, Sep 29, 2009 at 11:55 AM, Lucas Mocellin > wrote: > I have 2 programs(my GUI + firefox) for normal users "manage", > they will get lost without a WM. I want to be light but very > user-friendly. Simple to use. > > A kiosk sounds interesting to me, I had never heard about that > berfore. Firefox has an add-on, and works quite well. > > The problem is that I can't "set it up", I mean, firefox runs > in fullscreen, and what about my GUI? even though ALT + TAB > works, normal users won't know how to use it. I don't have a > panel like "window list applet" in gnome. ( *MAYBE* I could > design a GTK interface acting as a panel located on the top > and the option "always on top", what do you guys think > about? ) > > Also, I need a button to shutdown/restart. (that could be > located at that gtk panel). > > I'm looking at Linux kiosk and twm-kiosk, trying to compile > and test it. but looks like it will work to me. Have a look at matchbox: http://matchbox-project.org/ 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 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: proportional panning
On Mon, 2009-06-08 at 17:46 +0200, Matthias Hopf wrote: > On May 23, 09 19:24:31 +0100, David De La Harpe Golden wrote: > > But it's "border-push" type panning. That means to scroll new sections > > of the display into view you "push" against the border. Back in the > > day, some amiga stuff instead used "proportional" panning to move the > > viewport about the screen. Why would you want this? "Pushing" against > > a border means you need to push beyond where you want to click on to > > bring whatever it is fully on-screen, then move back. With the > > proportional way, every viewport pointer position corresponds to a > > particular point on the panning area. It allows rapid scrolling about > > large panning areas, at cost of some precision. > > Yes, you're right - I forgot how it was on the Amiga. Shame on me. > You're more than welcome to add this to the panning code. Why not making the proportional mode simply replace the push mode ? Why keeping an allegedly inferior panning mode ? 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: ATI +Gnome + CompizFusion = X crash
Le samedi 16 mai 2009 à 12:32 +, Felipe Lotas Asta a écrit : > Hi there. > > I've been looking for some weeks for a solution for this, and have > asked > in two forums but got no solution. > > I have: > ArchLinux > Gnome 2.26.1 > xorg-server 1.6.1-1 > xorg-server-utils 7.4-6 > compiz-fusion-plugins-main 0.8.2-1 > compiz-fusion-plugins-extra 0.8.2-1 > ATI Mobility Radeon X1400 > xf86-video-ati 6.12.2-2 > > The problem is that Compiz is very unstable. Hi, I think it's a bug in mesa, and may be fixed in the next release (cross fingers). 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: 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: 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 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: 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: 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 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: Increasing the frame buffer size
You can add a directive in your Xorg config file: Virtual 1920 1200 so that the maximum screen size is correct for you. Xav On Tue, 2009-01-06 at 08:54 -0800, Dirk Hohndel wrote: > I have a laptop with an Intel GM45. > When I start X without an external monitor attached, I get a > framebuffer size (or maximum screen size) of 1440x1440 as the internal > display is 1440x900. So when I try to connect my 24" external display, > I can't run it at 1920x1200 - that's not so good. > > Of course, if I start X WITH the external monitor attached, all is fine. > > So the question is "can I increase the size of the framebuffer without > restarting X?" Or do I have to somehow force a larger virtual display > to have enough space prereserved (I tried that in the config file, but > a lot of things have changed since I was fluent writing config files, > it seems... iow I didn't get it to work...) > > Thanks > > /D > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > ___ 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: 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 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: [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: [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: 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 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 ? I'll rebuild from today's git and check. 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: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: > > > > 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. > > > > > > 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). 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:27 +0100, Michel Dänzer wrote: > On Thu, 2008-11-06 at 10:20 +0100, Xavier Bestel wrote: > > 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. > > Is that only when using rotation, or even otherwise? Even otherwise. 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: LBX? or faster remote X?
Le mardi 04 novembre 2008 à 12:13 -0600, Jeremy C. Reed a écrit : > I don't see lbxproxy listed in the X.org 7.4 release. But it is in 7.3. > What is its status? > > I found docs online about LBX, but most are very old. > > xdpyinfo doesn't show any LBX extension for me (but I read online that > recent X servers include it by default). > > Before I attempt to rebuild Xorg with LBX, please let me know if this is > worth my time. > > Any alternatives? > > In my case, I am trying to view hundred page PDFs over a 980 to 1361 > KB/second connection over a 802.11 wireless network. It is way too slow. > I guess a real alternative instead of remote X is to use network file > system and actually run the X client on my local X server. Or use VNC. It's still unmatched. 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 "" (**) | |-->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, versi
Re: Rotate trouble on r300 (was: Re: XRandR rotate support HW rotate or not?)
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: > > 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? Disabling page flipping helps a lot, thank you ! Now it works perfectly well. I didn't try disabling tiling yet. Should I ? Thanks, Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
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
no more git ?
Hi, it seems anonymous git is broken right now: fatal: read error (Connection reset by peer) Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 7.5 release plans
On Fri, 2008-09-12 at 15:08 +0100, Sergio Monteiro Basto wrote: > On Fri, 2008-09-12 at 12:42 +0300, Daniel Stone wrote: > > On Fri, Sep 12, 2008 at 04:00:34AM +0100, Sergio Monteiro Basto wrote: > > > On Thu, 2008-09-11 at 23:23 +0300, Daniel Stone wrote: > > > > So here's roughly what I think 7.5 should look like: > > > > * Nowish: Release 7.4. Yeah. To the pub! > > > > > > Instead we release 7.3.1 with xserver 1.4.2 !? ( I leave happily with > > > it ) > > > No, who said anything about 7.3.1? > > Nowish means: "don't want" or am I missing something . You're missing something: "nowish" means "more or less now". It's not some contraction for "I don't wish that" :) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Thu, 2008-09-11 at 11:59 -0400, Kristian Høgsberg wrote: > We can then add the CRTC to sync to as an argument > later if we find a case where the client really can make a better > decision than the server. I can think of such an imaginary case: imagine an NLE (video editor) which only cares about a small portion of its window where the film is actually previewed. Then it would want to sync to the monitor displaying this region. Xav PS: ring again if you need useless thinking :) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
