Re: XGetImage returns junk with Xorg/dummy_drv/VTs

On Fri, Nov 21, 2008 at 03:23:03PM -0700, McDonald, Michael-p7438c wrote:
>   I'm trying to run the Xorg server using the dummy driver in the
> "background" in Linux. Everything works fine as long as the dummy Xorg
> has the VT "focus". If it's in the background, then XGetImage returns
> junk data.
> 
>   It seems like the VT code is somehow causing the framebuffer to get
> swapped out. Can someone give me a hint as to what's going on? And how
> to work around it if there is a work around?
> 
>   Or how to compile Xorg with VT support?

Yeah, when you don't have vtSema, your rendering is just random crap.
You probably want Xvfb instead of Xorg+dummy.

Cheers,
Daniel

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

how to get fake input events to a Xinput2 master device?

Hi there!

My first post on this list...

I am currently trying to create a networked multi-user collaboration
environment, based on Peter Hutterers great MPX (for the multi user
part) and x11vnc (networking) as part of a university project.

So far i've got MPX up and running, the question i now have is:
How can i make x11vnc create a new Master Device (or Slave Device) for
each connected client and route this client's input events to the
corresponding master device?

So far i see two possibilities:

(1) Master Devices created on the fly:
I know it's possible to create MD's via xinput, but i've got no idea
how to get application-generated events (from x11vnc) to a specific
master device. Via XTEST maybe? But according to
http://www.x.org/docs/Xext/xtestlib.pdf there's no way to address a
specific master device. I've read the Xlib docs as well and found
nothing on that. The Xinput docs weren't fruitful neither... But I'm
sure there must be a way to do it in userspace?

(2) Fake Slave Devices
If there's no way of doing things like in (1), i would have to rely on
faking slave devices and attach these to master devices. As a slave
device represents a physical device, i think there's no way of creating
one via xinput. So i thought about sth. like creating a SD with the

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