Re: Radeon X300, dual head

On Fri, Nov 21, 2008 at 03:53:51PM -0800, James Purdy wrote:
> Hi,
> 
> I am using the exact same setup on the exact same harware.  Radeon X300 + 2
> 1680x1050 monitors.  This may not be the best solution, but I use a shell
> script that runs after xorg starts with the command:
> xrandr --output DVI-0 --right-of VGA-0
> 
> and it spread a single desktop across 2 monitors.  Adjust --right-of and
> --left-of as necessary... of course your mileage may vary.

Yes, of course that's how it should be and what I tried first. This still
gives me the same output on both monitors.

I also configured a virtual screen size of 3360x1050 in xorg.conf, and tried
to push the second monitor to the other half of the screen with
xrandr --output VGA-0 --pos 1680x0, but that doesn't help either. All I can
achieve is a bigger screen size, I mean, the mouse cursor can be moved beyond
the left or right border of the screen. But it just disappears, I can never
see the other half of the screen. And it's always the same content on both
monitors.

Thanks,
Hans

> 
> 
> James
> 
> On Fri, Nov 21, 2008 at 2:50 PM, Hans J. Koch <hjk <at> linutronix.de> wrote:

Radeon X300, dual head

Hi,
I used to have a working system with a Radeon X300 (RV370) card and two
monitors 1680x1050 each. I used an ancient xorg version (something like
6.8, can't recall) and had a MergedFB+Xinerama configuration. Worked well
for me.

A few days ago I dist-upgraded my Debian sid which brought me version
7.3 of xserver-xorg. Since that I'm trying to get my dual head setup
working again...

I understand that MergedFB has been replaced by RandR 1.2 extensions.
Sounds like a good concept to me, but unfortunately it doesn't work here.

X correctly detects my hardware, but no matter what I do, I always have
the same output on DVI-0 and VGA-0. I googled around and found a lot of
pages describing how to setup xorg.conf, and I think it's OK.

Question: Is this supposed to work or a known problem? What do I have
to do to get a working dual head setup again?

Thanks,
Hans

Re: Frame buffer Changed Event.

On Fri, 2008-11-21 at 17:43 +0800, Leandro Galvez wrote:
> Hi All,
>  
>     I am using Xorg on top of Linux virtual frame buffer. What type of
> event or hook should I use to catch events after any part of the frame
> buffer has been updated? I would like to catch events that would
> trigger right after the frame data buffer has changed so I could feed
> the contents of the vfb to an actual device that can display it. I
> would like to catch the events globally and not just in specific
> applications.

The Damage extension sounds like it's right up your alley.

- ajax

_______________________________________________
xorg mailing list
xorg <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] xfree86: don't reset Auto(Add|Enable)Devices, use defaults from xf86Globals

Hi all,

Without this commit, Peter's earlier patch "xfree86: without CONFIG_HAL,
Auto{Add|Enable}Devices and AEI is false" still doesn't fully fix the issue.

Thanks

-- 
Rémi Cardona
LRI, INRIA
remi.cardona <at> lri.fr
remi <at> gentoo.org

From fba740a5662539938f4f825347912521b6b506d8 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?R=C3=A9mi=20Cardona?= <remi <at> gentoo.org>
Date: Fri, 21 Nov 2008 16:39:00 +0100
Subject: [PATCH 04/42] xfree86: don't reset Auto(Add|Enable)Devices, use defaults from xf86Globals

Without this, commit ace38fafb062372dcd3d56378b5b8f86525c6241 is useless
when HAL support is disabled.
---
 hw/xfree86/common/xf86Config.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index e91eadd..b6b4203 100644
--- a/hw/xfree86/common/xf86Config.c
+++ b/hw/xfree86/common/xf86Config.c
@@ -922,7 +922,6 @@ configServerFlags(XF86ConfFlagsPtr flagsconf, XF86OptionPtr layoutopts)

Re: Dual Head DVI on Q965/Q963 Express Chipset Family

Regarding the devices, I do not have the exact pci device id
at the moment. The intel ICH9 family
contains pci register id's for this board. I will email you with this
information in a few days. The detection is easily addressed from the
configuration. I will check out and verify any code changes as they
occur.

In my limited experience, if one SDVO output is used, with say a VGA/SDVO
combination, the SDVOB is used, and if two are used, then SDVOB/C are
used. The bios appears to enforce this. I have only seen 1 real example
though. I've never used other outputs. The LVDS configuration in the
config file was a hangover from another setup. It merely specified an
unused monitor.

I don't believe probing for connected terminals with the GMBUS/i2c on
the SDVO outputs is a big deal. Some bare metal programming allows the 
fact of monitor connection to be determined within a few hundred
microseconds. The VGA output connection state can be determined by reading a
bit in a register. Let me know if you want more details, as it is some
time since I have attended this subject.

On a related note, I noticed that if one attempts to enable
page-flipping, the xorg intel driver ultimately disables it with the comment
that the version of drm is insufficient, less than 1.9. However in the
code the check is for the minor version number only, and the current drm
version, 2.4 or thereabouts, fails this check (src/i830_dri.c, at the
end of the function I830DRIScreenInit). I have to say that
enabling or disabling page-flipping and triple buffering options make no
difference to my display. It acts as if they are enabled anyway,
which is probably a good thing, except that interrupts are being lost somewhere.

cgit question [was Re: Problems with keyboard using evdev]

On Friday 21 of November 2008, Peter Hutterer wrote:

> Note that for 1.5.3 you need one extra patch:
> http://cgit.freedesktop.org/xorg/xserver/commit/?id=0b56b44addc323a00eb7cd8
>6240cb0dd4275bcf8

btw. does anyone know how to download raw patch in cgit?

> Cheers,
>   Peter

--

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/
_______________________________________________
xorg mailing list
xorg <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Problems with keyboard using evdev

Dne petek 21. novembra 2008 je Peter Hutterer napisal(a):
> update to evdev 2.1 and server 1.5.3 or master.
>
> Note that for 1.5.3 you need one extra patch:

Thanks, works now :]

Cheers,
Matija

--

-- 
gsm: +386 41 849 552
e-mail: matija.suklje <at> rutka.net
www: http://matija.suklje.name

aim: hookofsilver
icq: 110183360
jabber/g-talk: matija.suklje <at> gabbler.org
msn: matija.suklje <at> rutka.net
yahoo: matija_suklje
GPG/PGP fingerprint: FB64 FFAF B8DA 5AB5 B18A 98B8 2B68 0B51 0549 D278

_______________________________________________
xorg mailing list
xorg <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [RFC][PATCH] ELD routines and proc interface

Hi Shane,

On Thu, Nov 20, 2008 at 12:06:06PM -0800, Shane W wrote:
> Hi,
> 
> Ok, it appears to be the kernel I was using.  Going to a
> 2.6.27 kernel rather than 2.6.28-rc fixed the segfault.  So
> now I get ELD data though 5.1 PCM isn't quite there yet. 
> Here's the ELD info.

Thanks.

> HDMI intrinsic event: PD=1 ELDV=1
> detected monitor Haier TV*** at connection type HDMI
> supports coding type LPCM: channels = 2, rates = 44100
> 48000 88200 176400 192000 384000, bits =
> supports coding type LPCM: channels = 8, rates = 44100
> 48000 88200 176400 192000 384000, bits =

It reveals bugs in showing the bits field. Will fix it in a following
email.

> supports coding type AC-3: channels = 6, rates = 44100
> 48000 88200, max bitrate = 640000
> supports coding type DTS: channels = 7, rates = 44100 48000
> 88200 176400 192000, max bitrate = 1536000
> supports coding type DSD (One Bit Audio): channels = 6,
> rates = 48000

It's weird that DTS supports 7 channels while DSD supports 6.

Re: VIA documentation release and the OpenChrome project

Xavier Bachelot wrote:
> We could use some help to improve the driver at a quicker pace. Please
> subscribe to the openchrome-devel mailing list if you'd like to join us.
> http://wiki.openchrome.org/mailman/listinfo/openchrome-devel
> 
Please see these mails for more details :
http://wiki.openchrome.org/pipermail/openchrome-users/2008-November/005029.html
http://wiki.openchrome.org/pipermail/openchrome-devel/2008-November/000121.html

Sorry about the double posting.

Regards,
Xavier

Re: Problems with keyboard using evdev

Dne petek 21. novembra 2008 je Matija Šuklje napisal(a):
> I get an error when trying to get Portage to patch it — I'm attaching the
> patch error output.

Nevermind ...I found out that the "x11" Gentoo overlay has the 1.5.3 ebuild 
with that patch and I'm trying that now.

Cheers,
Matija

--

-- 
gsm: +386 41 849 552
e-mail: matija.suklje <at> rutka.net
www: http://matija.suklje.name

aim: hookofsilver
icq: 110183360
jabber/g-talk: matija.suklje <at> gabbler.org
msn: matija.suklje <at> rutka.net
yahoo: matija_suklje
GPG/PGP fingerprint: FB64 FFAF B8DA 5AB5 B18A 98B8 2B68 0B51 0549 D278

_______________________________________________
xorg mailing list
xorg <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Problems with keyboard using evdev

Hullo,

my migrating to HAL saga has hit another rock — the keyboard.

I've switched my keyboard settings to HAL as well, because when I moved my 
mouse and touchpad to HAL and left the keyboard settings in 'xorg.conf', the 
keyboard really went crazy (e.g. repeated every key pressed three times).

What happens now is that some keybindings seem to work like they do in the 
console (instead of like they should in X). Examples:
* Ctrl+c kills X
* Ctrl+Backspace kills X
* "WinKey" goes a VT backwards (e.g. from tty7 to tty6)
* "MenuKey" goes a VT forwards (e.g. from tty7 to tty8)
* Ctrl+Fx goes to the VT 'x' (e.g. Ctrl+F1 goes to tty1, Ctrl+F12 goes to 
tty12)
* Alt+ArrowLeft goes a VT backwards
* Alt+ArrowRight goes a VT forwards

I'm pretty sure there's a simple solution that I'm unable to see. I'm just 
waiting for enlightenment and in the meantime cursing the 0's and 1's out of 
my laptop each time I forget myself and press Ctrl+c or Ctrl+Backspace to 
kill a program in the terminal emulator or try to delete a word.

I'm attaching the .fdi file I wrote — the (practical) problem persits no 
matter if I comment out any of its lines or not.

Here's the relevant 'hal-device' output:
--[start]--
43: udi