Re: [PATCH 1/3] introduce i830_hdmi_priv.has_hdmi_sink

[Wang, Zhenyu Z]

On 2008.11.07 14:23:39 +0800, Wu Fengguang wrote:
> HDMI is compatible with DVI, and we've seen many boards that
> use HDMI port for DVI output.
> 
> So Zhenyu proposed this flag: i830_hdmi_priv.has_hdmi_sink
> to indicate the presence of HDMI capable monitors.
> 
> Signed-off-by: Wu Fengguang <[EMAIL PROTECTED]>

> @@ -180,6 +184,16 @@ i830_hdmi_detect(xf86OutputPtr output)
>  edid_mon = xf86OutputGetEDID (output, intel_output->pDDCBus);
>  if (!edid_mon || !DIGITAL(edid_mon->features.input_type))
>   status = XF86OutputStatusDisconnected;
> +
> +if (xf86MonitorIsHDMI(edid_mon))
> + dev_priv->has_hdmi_sink = TRUE;
> +
> +if (pI830->debug_modes)
> + xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> + "%s monitor detected on HDMI-%d\n",
> + dev_priv->has_hdmi_sink ? "HDMI" : "DVI",
> + (dev_priv->output_reg == SDVOB) ? 1 : 2);
> +
>  xfree(edid_mon);
>  return status;
>  }

We should check if the symbol is available for xserver compatiblity.
So below is updated patch for check this. 

I'm fine with this patch sets and tested against sony bravia doesn't
show Shane's problem.

From 4da8170b0b949102c12b5957c80c46bc70ba1bbc Mon Sep 17 00:00:00 2001
From: Wu Fengguang <[EMAIL PROTECTED]>
Date: Wed, 12 Nov 2008 23:10:58 +0800
Subject: [PATCH] introduce i830_hdmi_priv.has_hdmi_sink

HDMI is compatible with DVI, and we've seen many boards that
use HDMI port for DVI output.

So Zhenyu proposed this flag: i830_hdmi_priv.has_hdmi_sink
to indicate the presence of HDMI capable monitors.

Signed-off-by: Wu Fengguang <[EMAIL PROTECTED]>
---
 src/i830_hdmi.c |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/src/i830_hdmi.c b/src/i830_hdmi.c
index 806ca7d..a3e3ba8 100644
--- a/src/i830_hdmi.c
+++ b/src/i830_hdmi.c
@@ -38,6 +38,8 @@ struct i830_hdmi_priv {
 uint32_t output_reg;
 
 uint32_t save_SDVO;
+
+Bool has_hdmi_sink;
 };
 
 static int
@@ -142,6 +144,8 @@ i830_hdmi_detect(xf86OutputPtr output)
 xf86OutputStatus status;
 xf86MonPtr edid_mon;
 
+dev_priv->has_hdmi_sink = FALSE;
+
 /* For G4X desktop chip, PEG_BAND_GAP_DATA 3:0 must first be written 0xd.
  * Failure to do so will result in spurious interrupts being
  * generated on the port when a cable is not attached.
@@ -180,6 +184,17 @@ i830_hdmi_detect(xf86OutputPtr output)
 edid_mon = xf86OutputGetEDID (output, intel_output->pDDCBus);
 if (!edid_mon || !DIGITAL(edid_mon->features.input_type))
status = XF86OutputStatusDisconnected;
+
+if (xf86LoaderCheckSymbol("xf86MonitorIsHDMI") &&
+   xf86MonitorIsHDMI(edid_mon))
+   dev_priv->has_hdmi_sink = TRUE;
+
+if (pI830->debug_modes)
+   xf86DrvMsg(pScrn->scrnIndex, X_INFO,
+   "%s monitor detected on HDMI-%d\n",
+   dev_priv->has_hdmi_sink ? "HDMI" : "DVI",
+   (dev_priv->output_reg == SDVOB) ? 1 : 2);
+
 xfree(edid_mon);
 return status;
 }
@@ -232,6 +247,7 @@ i830_hdmi_init(ScrnInfoPtr pScrn, int output_reg)
 
 dev_priv = (struct i830_hdmi_priv *)(intel_output + 1);
 dev_priv->output_reg = output_reg;
+dev_priv->has_hdmi_sink = FALSE;
 
 intel_output->dev_priv = dev_priv;
 intel_output->type = I830_OUTPUT_HDMI;
-- 
1.5.6.5


-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

change /root/xorg.conf.new

[wolk]

How to change default path(/root/xorg.conf.new) for Xorg -configure?
I need autodetection but my /root is ro. I want to save config to /tmp
 

Jacek
--
System poczty na jablko.one.pl

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Mouse button problems using Logitech NX80

[Peter Hutterer]

On Wed, Nov 12, 2008 at 01:23:49AM +0100, Matija Šuklje wrote:
> Hmmm, I tried using Fluxbox instead of KDE and in Fluxbox it works as 
> expected 
> (just as it does in KDM) ...so it seems that KDE messes it up later on when 
> the user session starts.

there's a chance that this is done automatically to accommodate for the
left-handed/right-handed mouse setting. IIRC gnome does something similar.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Mouse button problems using Logitech NX80

[Dan Nicholson]

On Sun, Nov 9, 2008 at 9:41 PM, Matija Šuklje <[EMAIL PROTECTED]> wrote:
> Hullo,
>
> For my birthday I got a Logitech NX80 mouse and I'm having problems setting it
> up on X.
>
> What I found out about the mouse:
> - wireless
> - laser (resolution: 1000)
> - has standard left and right mouse buttons — buttons 1 and 3 as usual
> - wheel has two speeds/tractions which are triggered by pressing the wheel —
> buttons 4 and 5 as usual
> - wheel can tilt and therefore scroll horizontally — buttons 7 and 6 (yes,
> they're inverted!)
> - pressing the wheel changes the (mechanical) speed of the wheel — button 2 is
> missing
> - there are two additional buttons on the far right front corner — buttons 8
> and 9

One thing I forgot to mention is that normally these side buttons are
used for forward and back in a web browser (or similar application). I
forget what the kernel calls them (you can test with evtest on the
console), but in firefox 3 buttons 8 and 9 should move you forward and
backwards in your history. Obviously, you can remap them to whatever
you want, but that is the original intention.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Mouse button problems using Logitech NX80

[Matija Šuklje]

Dne sreda 12. novembra 2008 je Peter Hutterer napisal(a):
> if it works in this config, shift the blame to KDE :)

Hmmm, I tried using Fluxbox instead of KDE and in Fluxbox it works as expected 
(just as it does in KDM) ...so it seems that KDE messes it up later on when 
the user session starts.

Tested with these settings:
---[xorg.conf]---
Identifier  "Mouse"
Driver  "evdev"
#Option "Name"  "Logitech USB Receiver"
Option  "Device""/dev/input/event4"
Option  "Resolution""1000"
#Option "Emulate3Buttons"   "true"
#Option "Buttons"   "9"
Option  "ButtonMapping" "1 0 3 4 5 6 7 8 2"
#Option "ZAxisMapping"  "4 5 7 6"
---[/xorg.conf]---

---[fdi file]---



  

  
1 0 3 4 5 6 
7 8 2
  

  

---[/fdi file]---

Cheers,
Matija
-- 
gsm: +386 41 849 552
e-mail: [EMAIL PROTECTED]
www: http://matija.suklje.name

aim: hookofsilver
icq: 110183360
jabber/g-talk: [EMAIL PROTECTED]
msn: [EMAIL PROTECTED]
yahoo: matija_suklje
GPG/PGP fingerprint: FB64 FFAF B8DA 5AB5 B18A 98B8 2B68 0B51 0549 D278


signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Synaptics patch: orientation

[Mildred Ki'Lya]

Le Tue 11/11/2008 à 18:32 Magnus Kessler à écrit:
> Not necessarily ;). I for one have been using a number of desktop
> keyboards with a built-in touchpad over the years. Alternatively
> there are stand-alone touchpads on the market as well.

Oh, That's interesting.

Since I have a laptop I find it really awkward not to be able to use a
trackpad on desktops, it is very useful to have it just under the
keyboard.

Mildred

-- 
Mildred Ki'Lya
╭─ ｍｉｌｄｒｅｄ５９３＠ｏｎｌｉｎｅ．ｆｒ ──
│ Jabber, GoogleTalk: <[EMAIL PROTECTED]>
│ Site:   GPG ID: 9A7D 2E2B
│ Fingerprint: 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 9A7D 2E2B
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Mouse button problems using Logitech NX80

[Peter Hutterer]

On Tue, Nov 11, 2008 at 11:44:38AM +0100, Matija Šuklje wrote:
> * scroolling works correctly in both ways now — OK
> * in 'KDM' the 8th and 9th button act as the middle one (and there is no 3rd 
> button emulation) — OK
> * in a KDE session though, the 8th and 9th button act as the left mouse 
> button 
does KDE send a SetPointerMapping request on login/startup? If so, that'd
override whatever you have configured in the config.

try starting your X server just by running "xinit --", you should get an
xterm, enough to start xev and debug the buttons.

if it works in this config, shift the blame to KDE :)

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Mouse button problems using Logitech NX80

[Matija Šuklje]

Dne torek 11. novembra 2008 je Matija Šuklje napisal(a):
> Dne torek 11. novembra 2008 je Dan Nicholson napisal(a):
> > Does the tilt scrolling work correctly without remapping buttons 6 and 7?
>
> Without ButtonMapping, the tilt scrolling works as expected, but
...but I still get the "middle button" emulation and useless buttons 8 and 9 
(where I would like to have the "middle button").

The same applies when I have both the '.fdi' file present and the 
ButtonMapping option in 'xorg.conf'.

It does seem to be possible to map these buttons, since as Thomas suggested, I 
am able to bind them to the desired effect using 'xmodmap -e "pointer = 1 9 3 
4 5 6 7 8 2"', but I feel this should be properly done in 'xorg.conf' and the 
xmodmap way feels kind of dirty to me.

Cheers,
Matija
-- 
gsm: +386 41 849 552
e-mail: [EMAIL PROTECTED]
www: http://matija.suklje.name

aim: hookofsilver
icq: 110183360
jabber/g-talk: [EMAIL PROTECTED]
msn: [EMAIL PROTECTED]
yahoo: matija_suklje
GPG/PGP fingerprint: FB64 FFAF B8DA 5AB5 B18A 98B8 2B68 0B51 0549 D278


signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Mouse button problems using Logitech NX80

[Matija Šuklje]

Dne torek 11. novembra 2008 je Thomas Lübking napisal(a):
> this can easily be fixed with xmodmap, just reorder the button numbers (so
> if mb 7/6 works for you: >> xmodmap -e "pointer = 1 2 3 4 5 7 6 8 9 10 11
> 12" <<) 7 & 6 are twisted. the same way you can attach mb2 to e.g. 8:
> xmodmap -e "pointer = 1 8 3 4 5 7 6 2 9 10 11 12"

This works, but I'd rather have it work from the xorg.conf itself ...thanks 
for a solution though :]


Cheers,
Matija

-- 
gsm: +386 41 849 552
e-mail: [EMAIL PROTECTED]
www: http://matija.suklje.name

aim: hookofsilver
icq: 110183360
jabber/g-talk: [EMAIL PROTECTED]
msn: [EMAIL PROTECTED]
yahoo: matija_suklje
GPG/PGP fingerprint: FB64 FFAF B8DA 5AB5 B18A 98B8 2B68 0B51 0549 D278


signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Mouse button problems using Logitech NX80

[Matija Šuklje]

Dne torek 11. novembra 2008 je Dan Nicholson napisal(a):
> Does the tilt scrolling work correctly without remapping buttons 6 and 7?

Without ButtonMapping, the tilt scrolling works as expected, but 

> /etc/hal/fdi/policy/logitech-receiver.fdi that maps the options to the
> HAL-style input.x11_options.$name format.

Adding such a file, sadly, didn't change anything — with ButtonMapping turned 
off in the xorg.conf, I get the right tilt scrolling, but now in get both in 
KDM and KDE the "middle button" emulation and the buttons 8 and 9 without a 
function.

Cheers,
Matija
-- 
gsm: +386 41 849 552
e-mail: [EMAIL PROTECTED]
www: http://matija.suklje.name

aim: hookofsilver
icq: 110183360
jabber/g-talk: [EMAIL PROTECTED]
msn: [EMAIL PROTECTED]
yahoo: matija_suklje
GPG/PGP fingerprint: FB64 FFAF B8DA 5AB5 B18A 98B8 2B68 0B51 0549 D278


signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Debugging glX apps

[tom fogal]

I'm hitting an issue appropriately establishing a glX context (it
seems), and I'm looking for a good way to debug it.

Quick overview in case someone happens to recognize the issue: I'm
getting a segfault in X functions when trying to initialize GLEW.
XOpenDisplay has succeded, and I'm not sure yet if glXCreateContext
succeeded, but it seems like the library I'm using would have aborted
if it had failed.  Call stack:

#0 XQueryExtension () from /usr/lib64/libX11.so.6
#1 XInitExtension () from /usr/lib64/libX11.so.6
#2 XextAddDisplay () from /usr/lib64/libXext.so.6
#3 ?? () from /usr/lib64/libGL.so.1
#4 glXQueryVersion () from /usr/lib64/libGL.so.1
#5 glxewContextInit () at glew/src/glew.c:6987
#6 glewInit () at glew/src/glew.c:7186

(addresses removed)

Is there a list of environment variables which affect X / GLX
behavior?  For example, it would be nice if I could set an environment
variable which would force XSynchronize(3) to `on', or cause library
functions to abort() rather than return error codes.

Any other tips for debugging?  My next step[s] are to build private
debug versions of some X libraries and force loading them via
LD_LIBRARY_PATH or similar.

Thanks,

-tom
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: radeon vs radeonhd drivers

[Gene Heskett]

On Tuesday 11 November 2008, Matthias Hopf wrote:
>On Nov 10, 08 22:15:24 -0500, Gene Heskett wrote:
>> Never mind, the answer is yes, monitor powerdown works using the radeon
>> driver, but doesn't using the radeonhd driver.
>
>radeonhd does support DPMS, it should just work (TM).

Here, we don't honor that trademark unless its capitalized. :)

Anyway, where is (url to sub) the radeondh list?

>Maybe check on the radeonhd mailing list, you're more likely getting
>support over there. If you're running on git, you might want to think
>about reporting a bug in bugzilla.

No git, x is straight F8.  Kernels I bleed from, copiously at times, currently 
2.6.28-rc3 with a patch to control the wilder swappiness which seems to be 
working fine.

>Matthias

Thanks Matthias

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
QOTD:
"I never met a man I couldn't drink handsome."
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Is there a maintainer for proto/trapproto, lib/libXTrap, app/xtrap, and Xorg XTRAP extension?

[Adam Jackson]

On Tue, 2008-11-11 at 16:25 +0100, Peter Breitenlohner wrote:

> Nevertheless, I think things have to be done more or less in the order I
> mentioned, not needing, however, any significant delay in between.
> And xtrapddmi.h can be dropped.
> 
> I could prepare patches for the items 3.1. and 3.2. from my list, but would
> need someone to review and apply them. Would you?

Sure.

> Is there a way to move a file between modules while preserving the original
> author (git blame) of that file?

Not that I'm aware of.  But for this case I'm not too worried about it.

- ajax


signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Graphics not always refreshing (Intel)

[John Ettedgui]

On Mon, Nov 10, 2008 at 12:50 PM, John Ettedgui <[EMAIL PROTECTED]>wrote:

>
>
> On Mon, Nov 10, 2008 at 12:41 PM, Tassilo Horn <[EMAIL PROTECTED]>wrote:
>
>> "John Ettedgui" <[EMAIL PROTECTED]> writes:
>>
>> Hi John,
>>
>> > [redisplay problems with intel driver]
>>
>> I had similar troubles and work around them by adding the line
>>
>>Option "FramebufferCompression" "off"
>>
>> to my Device section.  There's an xorg bug report concerning this
>> issue.  I guess with the option as search string you'll find it.
>>
>> Bye,
>> Tassilo
>> --
>> Windows: So easy to admin, even a worm can do it.
>>
>> __
>
>
I tried that and it worked.

Thank you,

John
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Synaptics patch: orientation

[Magnus Kessler]

On Tuesday 11 November 2008, Mildred Ki'Lya wrote:
> Hi,
>
> Le Tue 11/11/2008 à 15:21 Éric Piel à écrit:
> > > The next thing would be to automatically change the orientation of
> > > the trackpad when XRandR rotates the screen.
> >
> > Certainly not at the X server level. I have two screens, which
> > screen's orientation are you going to use? However, at a higher
> > level, like in the gnome applet for screen resolution, that would be
> > very useful.
>
> I was thinking at a higher level (like the gnome applet). But why not
> at the lower level (if specifically allowed in xorg.conf). The screen
> that would be monitored would be of course the laptop's screen (LVDS
> for me).
>
> Well, I guess that if you have a trackpad it's on a laptop, right?

Not necessarily ;). I for one have been using a number of desktop keyboards 
with a built-in touchpad over the years. Alternatively there are stand-alone 
touchpads on the market as well.

Magnus
>
> :)
>
> Mildred


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Access Control question

[Dan Nicholson]

On Tue, Nov 11, 2008 at 6:50 AM, Adam Jackson <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-11-11 at 08:50 +0100, Alan James Caruana wrote:
>> Hi,
>>
>> I started an X Server with none of the parameters being "-ac" (i.e.
>> Access Control is NOT defeated) and I am NOT using XDMCP. As expected,
>> the X Server is only accepting X Clients from the local machine.  How
>> do I make the X Server accept X Clients from specific remote machines
>> also ? I am supposing that I would need to give the X Server some form
>> of an Access Control List, which I could do because I know which
>> remote machines I want to use.
>
> xhost +inet:www.example.org

Also, see Xserver(1) in the GRANTING ACCESS section about
/etc/X$DISPLAY.hosts files for a more static configuration.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Synaptics patch: orientation

[Mildred Ki'Lya]

Hi,


Le Tue 11/11/2008 à 15:21 Éric Piel à écrit:
>
> Hi,
> It's great, it's a feature I've been really looking for!
> However, I have a couple of comments.
> 
> First, as this is clearly following the xrandr notions, I think it
> should call the same things the same. So let's call it "rotation"
> instead of "orientation" (unless in the inside of the Xrandr protocol
> it's called orientation?).

Well, xrandr uses the option -o/--orientation at least for me (RandR
version 1.2)

> Also, the idea of rotation has nothing specific to the synaptics
> touchpad, it's just generic to any pointer device. For instance, I
> think there was recently some patches to swap the axes in the evdev
> driver. Shouldn't all this infrastructure be in a generic layer? At
> least, it would be good if all the drivers conformed to the same
> features, property names, and property behaviour :-)

The reason is very simple, I already had a look into the synaptics code
(to implement emulation of middle and right clock on apple touchpads
that only have a single button). It's the only piece of code from Xorg I
know and can patch. if I had to change the implementation in the X
server, it would have been more difficult (impossible for me now, I'm
willing to learn but unfortunately don't have much time for it and
don't know how to find information).

So I agree with you, but I couldn't do that.

But isn't there a work going on to have a common way to change the
configuration of Xorg modules ? Currently synaptics uses the shared
library but it may change in the future if some new method is found
more appropriate.

Also, a reason to have it directly in synaptics would be that it allows
synaptics to rotate some features (like the edges and corners, used to
scroll and emulate other clicks).

> Last but not least, as a user, only the rotation is useful. I don't
> care about "DontReportSize", "VertSpeed" and "HorizSpeed", they are
> just tricks that have to be done to get the touchpad correctly
> behaving after a rotation is applied. They should be computed
> automatically.

For the DontReportSize, it may not be necessary as it is perhaps
possible for synaptics to change dynamically the trackpad's dimensions,
but I didn't knew how to do that. Moreover, Xorg generally speed up an
axis and thus makes it impossible (in my case actually) to move the
cursor of only one pixel in one direction.

I choosed to put this options so the normal behaviour of synaptics
would be the same as usual (I don't want to send a patch that changes
the default behaviour yet). And since we cannot change this
dynamically (for example when the orientation changes), I had to
include it as an option.

And for the speed option, I thought it could be interesting to have
them as options (so the user could manually tweak them) but I agree on
that point I could have computed the speeds depending on the trackpad's
dimensions when DontReportSize is true.

> > The next thing would be to automatically change the orientation of
> > the trackpad when XRandR rotates the screen.
> Certainly not at the X server level. I have two screens, which
> screen's orientation are you going to use? However, at a higher
> level, like in the gnome applet for screen resolution, that would be
> very useful.

I was thinking at a higher level (like the gnome applet). But why not
at the lower level (if specifically allowed in xorg.conf). The screen
that would be monitored would be of course the laptop's screen (LVDS
for me).

Well, I guess that if you have a trackpad it's on a laptop, right?



:)

Mildred


-- 
Mildred Ki'Lya
╭─ ｍｉｌｄｒｅｄ５９３＠ｏｎｌｉｎｅ．ｆｒ ──
│ Jabber, GoogleTalk: <[EMAIL PROTECTED]>
│ Site:   GPG ID: 9A7D 2E2B
│ Fingerprint: 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 9A7D 2E2B
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: radeon vs radeonhd drivers

[Matthias Hopf]

On Nov 10, 08 22:15:24 -0500, Gene Heskett wrote:
> Never mind, the answer is yes, monitor powerdown works using the radeon 
> driver, but doesn't using the radeonhd driver.

radeonhd does support DPMS, it should just work (TM).
Maybe check on the radeonhd mailing list, you're more likely getting
support over there. If you're running on git, you might want to think
about reporting a bug in bugzilla.

Matthias

-- 
Matthias Hopf <[EMAIL PROTECTED]>  ____   __
Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__  [EMAIL PROTECTED]
Phone +49-911-74053-715   __)  |_|  __)  |__  R & D   www.mshopf.de
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

DMX+Jogl error

[Andres Felipe Molina Villamizar]

We're trying to run JOGL on top of DMX, on a 64bit Linux cluster (CentOS
5.2, nVidia Quadro 4600). It runs fine without DMX, but when I try to run it
inside DMX I get the following error:

java.lang.reflect.InvocationTargetException
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1020)
at
javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1348)
at com.sun.opengl.util.Animator.display(Animator.java:158)
at com.sun.opengl.util.Animator$MainLoop.run(Animator.java:181)
at java.lang.Thread.run(Thread.java:674)
Caused by: javax.media.opengl.GLException: Error making context current
at
com.sun.opengl.impl.x11.X11PbufferGLContext.makeCurrentImpl(X11PbufferGLCont
ext.java:90)
at
com.sun.opengl.impl.GLContextImpl.makeCurrent(GLContextImpl.java:134)
at
com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:182)
at
com.sun.opengl.impl.GLPbufferImpl.maybeDoSingleThreadedWorkaround(GLPbufferI
mpl.java:208)
at com.sun.opengl.impl.GLPbufferImpl.display(GLPbufferImpl.java:88)
at javax.media.opengl.GLJPanel.paintComponent(GLJPanel.java:659)
at javax.swing.JComponent.paint(JComponent.java:1041)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5164)
at
javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java
:302)
at javax.swing.RepaintManager.paint(RepaintManager.java:1145)
at javax.swing.JComponent._paintImmediately(JComponent.java:5112)
at javax.swing.JComponent.paintImmediately(JComponent.java:4922)
at
javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:740)
at
javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:696)
at com.sun.opengl.util.Animator$1.run(Animator.java:302)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:225)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:602)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java
:275)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:20
0)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java
:190)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:138)


I'm trying to use the example at the following URL:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6503420

It seems to me it is not a problem with the driver (as is suggested in the
bug description) since the program runs outside of DMX. Any hints?

Thanks in advance,



 



Andrés Molina

Ing. De Sistemas y Computación

Universidad de Los Andes

Grupo Imagine

 

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] to detail timing of EDID extension

[Adam Jackson]

On Tue, 2008-11-11 at 11:45 +0800, Ma, Ling wrote:
> Hi 
> Hi All
> In order not to pollute ABI xf86Monitor when we append new extensions
> such as CEA, VTB ,DI, LS, ... I did this patch , in which I moved  all
> original and extension detail timing operations into the unified
> interface (xf86ForEachDetailedBlock), then handle them respectively. I
> have finished test on my G45 & BenQ G2400W connected by HDMI.

A few remarks:

> +xf86ForEachDetailedBlock(ConfiguredMonitor, handle_detailed_input,
> + (void *)ptr);

No need for the explicit (void *) here.  The prototype already says it's
void *, and any pointer can be passed as void * without warning.

> @@ -64,12 +64,12 @@ handle_edid_quirks(xf86MonPtr m)
>   * similar.  Strictly we should refuse to round up too far, but let's
>   * see how well this works.
>   */
> -for (i = 0; i < 4; i++) {
> -   if (m->det_mon[i].type == DS_RANGES) {
> -   ranges = &m->det_mon[i].section.ranges;
> -   for (j = 0; j < 4; j++) {
> -   if (m->det_mon[j].type == DT) {
> -   preferred_timing = &m->det_mon[j].section.d_timings;
> +for (i = 0; i < det_mon_num; i++) {
> +   if (det_mon[i].type == DS_RANGES) {
> +   ranges = &det_mon[i].section.ranges;
> +   for (j = 0; j < det_mon_num; j++) {
> +   if (det_mon[j].type == DT) {
> +   preferred_timing = &det_mon[j].section.d_timings;
> if (!ranges->max_clock) continue; /* zero is legal */
> if (ranges->max_clock * 100 < 
> preferred_timing->clock) {
> xf86Msg(X_WARNING,

This is buggy.  You've made it so det_mon_num is the total number of
detailed sections in all blocks, including extensions, but not changed
the size of the det_mon array.  So this for loop will walk off the end
of the det_mon array.

This (and the other places where you iterate over det_mon_num) ought to
look more like:

---
@@ -52,11 +52,29 @@ static void get_detailed_timing_section(Uchar*, struct  
 static Bool validate_version(int scrnIndex, struct edid_version *);
 
 static void
+find_ranges_section(struct detailed_monitor_section *det, void *ranges)
+{
+if (det->type == DS_RANGES && !clock)
+   *ranges = &det->section.ranges;
+}
+
+static void
+find_max_detailed_clock(struct detailed_monitor_section *det, void *ret)
+{
+int *clock = ret;
+
+if (det->type == DT) {
+   struct detailed_timings *t = &det->section.d_timings;
+   *clock = max(*clock, t->clock);
+}
+}
+
+static void
 handle_edid_quirks(xf86MonPtr m)
 {
 int i, j;
 struct detailed_timings *preferred_timing;
-struct monitor_ranges *ranges;
+struct monitor_ranges *ranges = NULL;
 
 /*
  * max_clock is only encoded in EDID in tens of MHz, so occasionally we
@@ -64,25 +82,14 @@ handle_edid_quirks(xf86MonPtr m)
  * similar.  Strictly we should refuse to round up too far, but let's
  * see how well this works.
  */
-for (i = 0; i < 4; i++) {
-   if (m->det_mon[i].type == DS_RANGES) {
-   ranges = &m->det_mon[i].section.ranges;
-   for (j = 0; j < 4; j++) {
-   if (m->det_mon[j].type == DT) {
-   preferred_timing = &m->det_mon[j].section.d_timings;
-   if (!ranges->max_clock) continue; /* zero is legal */
-   if (ranges->max_clock * 100 < preferred_timing->clock) {
-   xf86Msg(X_WARNING,
-   "EDID preferred timing clock %.2fMHz exceeds "
-   "claimed max %dMHz, fixing\n",
-   preferred_timing->clock / 1.0e6,
-   ranges->max_clock);
-   ranges->max_clock =
-   (preferred_timing->clock+99)/100;
-   return;
-   }
-   }
-   }
+xf86ForEachDetailedBlock(m, find_ranges_section, &ranges);
+if (ranges && ranges->max_clock) {
+   int clock = 0;
+   xf86ForEachDetailedBlock(m, find_max_detailed_clock, &clock);
+   if (clock && (ranges->max_clock * 1e6 < clock)) {
+   xf86Msg(X_WARNING, "EDID timing clock %.2f exceeds claimed max "
+   "%dMHz, fixing\n", clock / 1.0e6, ranges->max_clock);
+   ranges->max_clock = (clock+99)/1e6;
}
 }
 
---

Admittedly I'm fixing one or two other bugs in the process there, but
you get the idea.  You really shouldn't ever be explicitly iterating
from zero to det_mon_num.

Also, calling edid_quirks() from xf86GetDetailTiming seems... confused.

> +static void handle_detailed_hvsize(struct detailed_monitor_section *det_mon,
> +   void *data)
> +{
> +float timing_aspect;
> +struct parameter{
> +int real_hsize;
> +int real_vsize;
> +float target_aspect;
> +}*p = (struct par

Re: Is there a maintainer for proto/trapproto, lib/libXTrap, app/xtrap, and Xorg XTRAP extension?

[Peter Breitenlohner]

On Tue, 11 Nov 2008, Adam Jackson wrote:

> XTrap was dropped from xserver mainline:
>
> http://cgit.freedesktop.org/xorg/xserver/commit/?id=cbc20d92de92aad5ca240310a9156ccf97c24a01

Hi Adam,

thanks for your quick answer.

> The motivation was that it seems to be redundant in the face of Record
> and Test:
>
> http://lists.freedesktop.org/archives/xorg/2008-June/036214.html
>
> So this probably makes any reorganization you want to do here quite a
> bit simpler.  I wouldn't worry about trying to preserve the ability to
> build older servers with newer versions of trapproto.

Nevertheless, I think things have to be done more or less in the order I
mentioned, not needing, however, any significant delay in between.
And xtrapddmi.h can be dropped.

I could prepare patches for the items 3.1. and 3.2. from my list, but would
need someone to review and apply them. Would you?

Is there a way to move a file between modules while preserving the original
author (git blame) of that file?

Regards,
Peter Breitenlohner <[EMAIL PROTECTED]>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: X locks when deactivating composite effects

[Michel Dänzer]

On Tue, 2008-11-11 at 15:56 +0100, Lubos Lunak wrote:
> On Tuesday 11 of November 2008, Michel Dänzer wrote:
> > On Mon, 2008-11-10 at 06:35 -0800, john terragon wrote:
> > > Hi,
> > >
> > > whenever I deactivate the composite effects the x server locks up and I
> > > get the following in the Xorg log file:
> ...
> > Yes, looks like https://bugzilla.redhat.com/show_bug.cgi?id=445331
> > (http://bugs.freedesktop.org/show_bug.cgi?id=7128 is probably related,
> > http://bugs.freedesktop.org/show_bug.cgi?id=18465 possibly).
> >
> > Basically, the problem is that the (AI)GLX code keeps pointers to
> > DrawableRec structs of X windows corresponding to GLX windows without
> > preventing/tracking the destruction of the X windows. So it can happen
> > that the (AI)GLX code dereferences these pointers after the X window is
> > already destroyed.
> >
> > It might be possible for the client (is that kwin for you as well?) to
> > avoid this problem by making sure that the GLX context is unbound and
> > destroyed before the X window is destroyed, not sure about that though.
> 
>  The bug appears to be in X (GLX1.3 docs seem to suggest in section 3.3.7 
> ["If 
> draw is destroyed after glXMakeContextCurrent is called,..."] that destroying 
> a window while a GLXContext using it is still current is allowed).

Sure, I was merely suggesting possible workarounds until the X server is
fixed.


-- 
Earthling Michel Dänzer   |  http://tungstengraphics.com
Libre software enthusiast |  Debian, X and DRI developer

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: X locks when deactivating composite effects

[Lubos Lunak]

On Tuesday 11 of November 2008, Michel Dänzer wrote:
> On Mon, 2008-11-10 at 06:35 -0800, john terragon wrote:
> > Hi,
> >
> > whenever I deactivate the composite effects the x server locks up and I
> > get the following in the Xorg log file:
...
> Yes, looks like https://bugzilla.redhat.com/show_bug.cgi?id=445331
> (http://bugs.freedesktop.org/show_bug.cgi?id=7128 is probably related,
> http://bugs.freedesktop.org/show_bug.cgi?id=18465 possibly).
>
> Basically, the problem is that the (AI)GLX code keeps pointers to
> DrawableRec structs of X windows corresponding to GLX windows without
> preventing/tracking the destruction of the X windows. So it can happen
> that the (AI)GLX code dereferences these pointers after the X window is
> already destroyed.
>
> It might be possible for the client (is that kwin for you as well?) to
> avoid this problem by making sure that the GLX context is unbound and
> destroyed before the X window is destroyed, not sure about that though.

 The bug appears to be in X (GLX1.3 docs seem to suggest in section 3.3.7 ["If 
draw is destroyed after glXMakeContextCurrent is called,..."] that destroying 
a window while a GLXContext using it is still current is allowed). I'll try 
to reshuffle the relevant KWin code though.

-- 
Lubos Lunak
KDE developer
--
SUSE LINUX, s.r.o.   e-mail: [EMAIL PROTECTED] , [EMAIL PROTECTED]
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9  fax: +420 284 028 951
Czech Republic   http://www.suse.cz
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Access Control question

[Adam Jackson]

On Tue, 2008-11-11 at 08:50 +0100, Alan James Caruana wrote:
> Hi,
> 
> I started an X Server with none of the parameters being "-ac" (i.e.
> Access Control is NOT defeated) and I am NOT using XDMCP. As expected,
> the X Server is only accepting X Clients from the local machine.  How
> do I make the X Server accept X Clients from specific remote machines
> also ? I am supposing that I would need to give the X Server some form
> of an Access Control List, which I could do because I know which
> remote machines I want to use.

xhost +inet:www.example.org

- ajax


signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Is there a maintainer for proto/trapproto, lib/libXTrap, app/xtrap, and Xorg XTRAP extension?

[Adam Jackson]

On Tue, 2008-11-11 at 11:48 +0100, Peter Breitenlohner wrote:
> Hi,
> 
> while looking through (gcc) compiler warnings I noticed, that the xtrap
> headers probably ought to be reorganized.
> 
> 1. Current status
> =
> 
> At the moment proto/trapproto installs these headers:
> 
> (A)   
>   
>   
> 
> (B)   
>   
>   
> 
> (C)   
> 
> where headers (A+B) are used by lib/libXTrap and app/xtrap,
> whereas (A+C) are used by the Xorg XTRAP extension.
> 
> Moreover, xtrapdi.h declares the non-prototype function pointer types
>   typedef int  (*int_function)();
> used by the Xorg XTRAP extension, as well as
>   typedef void (*void_function)();
> used by the Xorg XTRAP extension, lib/libXTrap, and app/xtrap.

XTrap was dropped from xserver mainline:

http://cgit.freedesktop.org/xorg/xserver/commit/?id=cbc20d92de92aad5ca240310a9156ccf97c24a01

The motivation was that it seems to be redundant in the face of Record
and Test:

http://lists.freedesktop.org/archives/xorg/2008-June/036214.html

So this probably makes any reorganization you want to do here quite a
bit simpler.  I wouldn't worry about trying to preserve the ability to
build older servers with newer versions of trapproto.

- ajax


signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Trying to understand vertex format for savage EXA composite

[Alex Deucher]

On Mon, Nov 10, 2008 at 3:26 PM, Alex Villací­s Lasso
<[EMAIL PROTECTED]> wrote:
> Good news! My machine rose itself from the dead while salvaging its memory
> chips, so now I can continue tinkering with the savage driver.
>
> Since a while ago, I am trying to write an EXA composite acceleration
> implementation for savage. I have gotten to the point that I can pipe a few
> vertices through BCI, and get something displayed on the screen as a result.
> However, this something is not what I intended. For example, the themed
> mouse cursor shows as a broken arrow bitmap, horizontally sliced, and it
> shifts and wraps sideways when moving it up and down.
>
> I suspect I am sending incorrect vertex values. The problem is that it is
> hard to find a documentation on the vertex format for the savage. What I
> found out is that I can trim down the vertex format to (x value, y value,
> source tex x, source tex y, mask tex x, mask tex y), and that all of these
> values are supposed to be 32-bit floats (glFloat values from what I can see
> in Mesa sources). But I am not sure of the mapping of the ranges of (x,y)
> coordinates into the values that are supposed to be emitted. The Mesa
> sources say that the savage is "DirectX-oriented", but I am not sure exactly
> what does this imply regarding the values of the vertex record. What I am
> sending is:
>
> x value, y value: value passed as destination coordinate (integer),
> converted as if by assignment to 32-bit floating point. A value of 8 gets
> converted to the bit representation of 8.0f, regardless of the destination
> width/height.
> texture coordinates: value converted from the range between 0 and the
> texture dimensions into the range 0.0f .. 1.0f . So if the texture of 128
> pixels wide has a coordinate of 64, this gets converted to the bit
> representation of 0.5f
>
> Is this the correct way to convert coordinates? Or should I do something
> different? I particularly suspect the destination coordinates, but I cannot
> find any documentation regarding this on google.

Your best bet it to look at the savage mesa and drm code.  It's been a
while since I looked at savage 3D, but it used directx vertex formats
directly (like lots of cards at the time).  As such much of the vertex
handling was done via vertex template code in mesa.   Another problem
may be the textures.  IIRC, they had to be tiled and had some strange
memory layouts.   You might ask on dri-devel.

Alex
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Synaptics patch: orientation

[Éric Piel]

Mildred Ki'Lya schreef:
> Hi,
> 
> I just finished my orientation patch for synaptics. It's not heavily
> tested for the moment. If anyone could test ...
> 
> I added 4 options to the driver, quoting from the man page:
> 
>Option "Orientation" "integer"
>   This option can be used to change the orientation of the  track‐
>   pad  and  can  takes  values  from  0  to 3. The default value 0
>   implies a normal orientation, other values can be used  to  have
>   respectively  an orientation set to the left, an inverted orien‐
>   tation, and an orientation set to the right.  This may be useful
>   in  combinaison with the orientation option of the XRandR exten‐
>   sion. You may notice that the values used are the  same  to  the
>   values  used  by  XRandR.   Along with this option, you might be
>   interested to enable the DontReportSize option. Read  its  docu‐
>   mentation to know why.
:
> 
>Option "DontReportSize" "boolean"
:
>
Hi,
It's great, it's a feature I've been really looking for!
However, I have a couple of comments.

First, as this is clearly following the xrandr notions, I think it
should call the same things the same. So let's call it "rotation"
instead of "orientation" (unless in the inside of the Xrandr protocol
it's called orientation?).

Also, the idea of rotation has nothing specific to the synaptics
touchpad, it's just generic to any pointer device. For instance, I think
there was recently some patches to swap the axes in the evdev driver.
Shouldn't all this infrastructure be in a generic layer? At least, it
would be good if all the drivers conformed to the same features,
property names, and property behaviour :-)

Last but not least, as a user, only the rotation is useful. I don't care
about "DontReportSize", "VertSpeed" and "HorizSpeed", they are just
tricks that have to be done to get the touchpad correctly behaving after
a rotation is applied. They should be computed automatically.

> The next thing would be to automatically change the orientation of the
> trackpad when XRandR rotates the screen.
Certainly not at the X server level. I have two screens, which screen's
orientation are you going to use? However, at a higher level, like in
the gnome applet for screen resolution, that would be very useful.

See you,
Eric
begin:vcard
fn;quoted-printable:=C3=89ric Piel
n;quoted-printable:Piel;=C3=89ric
org:Technical University of Delft;Software Engineering Research Group
adr:HB 08.080;;Mekelweg 4;Delft;;2628 CD;The Netherlands
email;internet:[EMAIL PROTECTED]
tel;work:+31 15 278 6338
tel;cell:+31 6 2437 9135
x-mozilla-html:FALSE
url:http://pieleric.free.fr
version:2.1
end:vcard

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Looking for API to possibly implement "mastered image transfer" for xf86-video-savage

[Alex Deucher]

On Mon, Nov 10, 2008 at 1:37 PM, Alex Villací­s Lasso
<[EMAIL PROTECTED]> wrote:
> In the reference documents for the savage video card, there is an
> operation called a "mastered image transfer", which looks like an
> accelerated pixmap upload into the framebuffer. This operation
> references registers with bit flags to select between "framebuffer
> memory" and "system memory". However, there are restrictions on the kind
> of "system memory" that is suitable for the transfer. The chipset can
> only use either:
>
> 1) PCI memory ("physically contiguous and page-locked")
> 2) AGP memory
>
> I understand "PCI memory" to mean the garden-variety userspace memory,
> which is paginated, and might be swapped out to disk (therefore the
> restrictions).
>
> The question is: is there any xserver support that might enable a driver
> to get pixmap data into either kind of situation? Either get the pixmap
> into physically contiguous pages and obtain the physical address of the
> start of data, or pre-copy the pixmap data into AGP memory (allocated by
> the driver on startup, if necessary) so that the driver does not need to
> copy it into AGP memory every single time. If either one exists, this
> might be useful to get a better implementation of EXAUploadToScreen, as
> well as a faster XVideo (which can also use system memory, according to
> the docs).

As Michel mentioned, this need drm support since since you'll need to
know physical addresses tom implement this.  Some of this may already
be implemented for vertex or texture uploads in the savage drm and
mesa driver, but I don't recall off hand.  If so you could probably do
something similar for EXA/Xv.

For UploadToScreen() the savage driver already implements this using a
hostdata blit.  I'm not sure how much advantage you'll gain by using
the DMA engine, but no one has benchmarked it so perhaps there is an
advantage.  For DownloadFromScreen(), it may be more useful.

Alex
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Intel: G45 X4500HD Core XvMC/VAAPI and Programmers manual

[Terry Barnaby]

Is there a programs manual available for the Intel G45 X4500HD Graphics
Core ?
I note the site: http://intellinuxgraphics.org has manuals
for the 965 and G43.

I am especially interested in the Hardware MPEG2/H264 Video decode
section.

Are there any plans to support XvMC or VAAPI at the VLD level and if
so has any work been done on this as yet ?

Cheers


Terry
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Mouse button problems using Logitech NX80

[Dan Nicholson]

On Tue, Nov 11, 2008 at 2:44 AM, Matija Šuklje <[EMAIL PROTECTED]> wrote:
> Dne torek 11. novembra 2008 je Peter Hutterer napisal(a):
>> correct. you could just upgrade to 2.1 RC3 from
>
> Alright, so I upgrated to 2.0.99.3 changed my xorg.conf to look like this:
>
>Identifier  "Mouse"
>Driver  "evdev"
>#Option "Name"  "Logitech USB Receiver"
>Option  "Device""/dev/input/event4"
>Option  "Resolution""1000"
>#Option "Emulate3Buttons"   "true"
>#Option "Buttons"   "9"
>Option  "ButtonMapping" "1 0 3 4 5 7 6 2 2"
>#Option "ZAxisMapping"  "4 5 7 6"
>
> And the results of thissetting now are:
> * scroolling works correctly in both ways now — OK

Does the tilt scrolling work correctly without remapping buttons 6 and 7?

> * in 'KDM' the 8th and 9th button act as the middle one (and there is no 3rd
> button emulation) — OK
> * in a KDE session though, the 8th and 9th button act as the left mouse button
> (and for some reason 3rd button emulation works)

Most likely this is because X is adding devices from HAL and skipping
the settings in xorg.conf. The way to solve this is to put your input
configuration in an fdi file and comment out the settings in
xorg.conf. Create a file like
/etc/hal/fdi/policy/logitech-receiver.fdi that maps the options to the
HAL-style input.x11_options.$name format.



  

  
1 0
3 4 5 7 6 2 2
  

  


--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Synaptics patch: orientation

[Mildred Ki'Lya]

Le Tue 11/11/2008 à 14:30 Peter Hutterer à écrit:
>
> please split the patch into 3 separate patches as grouped above. They
> are semantically different changes and shouldn't be applied in one go.
> Also, I'd prefer a git patch series over a standard diff. If you need
> help with that, just contact me off-list.
> 
> Once you've split it up, please CC me on the patch series and I'll
> have a look at them.


Well, I don't really know how to creates patch series using git. It was
easier for me to create a repository I made available on github:

git://github.com/mildred/xorg-synaptics-orientation-patch.git
http://github.com/mildred/xorg-synaptics-orientation-patch/

I also filled in extensive commit messages

Mildred


-- 
Mildred Ki'Lya
╭─ ｍｉｌｄｒｅｄ５９３＠ｏｎｌｉｎｅ．ｆｒ ──
│ Jabber, GoogleTalk: <[EMAIL PROTECTED]>
│ Site:   GPG ID: 9A7D 2E2B
│ Fingerprint: 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 9A7D 2E2B
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: X locks when deactivating composite effects

[Michel Dänzer]

On Mon, 2008-11-10 at 06:35 -0800, john terragon wrote:
> Hi,
> 
> whenever I deactivate the composite effects the x server locks up and I get 
> the following in the Xorg log file:
> 
> --
> Backtrace:
> 0: /usr/bin/X(xf86SigHandler+0x79) [0x80c1659]
> 1: [0xa7fc7400]
> 2: /usr/lib/xorg/modules/extensions//libdri.so(DRIGetDrawableInfo+0x2e) 
> [0xa7fb911e]
> 3: /usr/lib/xorg/modules/extensions//libglx.so [0xa7b24c6e]
> 4: /usr/lib/dri/radeon_dri.so(__driUtilUpdateDrawableInfo+0xc1) [0xa2d28011]
> 5: /usr/lib/dri/radeon_dri.so(radeonGetLock+0x75) [0xa2d2fe05]
> 6: /usr/lib/dri/radeon_dri.so(radeonFlushCmdBuf+0x90) [0xa2d2d910]
> 7: /usr/lib/dri/radeon_dri.so(radeonDestroyContext+0xbd) [0xa2d2c0cd]
> 8: /usr/lib/dri/radeon_dri.so [0xa2d27ec7]
> 9: /usr/lib/xorg/modules/extensions//libglx.so [0xa7b26849]
> 10: /usr/lib/xorg/modules/extensions//libglx.so(__glXFreeContext+0x89) 
> [0xa7b1bae9]
> 11: /usr/lib/xorg/modules/extensions//libglx.so [0xa7b1bb37]
> 12: /usr/bin/X(FreeResourceByType+0xe2) [0x80732f2]
> 13: /usr/lib/xorg/modules/extensions//libglx.so [0xa7b17e07]
> 14: /usr/lib/xorg/modules/extensions//libglx.so [0xa7b1be9a]
> 15: /usr/bin/X(Dispatch+0x34f) [0x808b74f]
> 16: /usr/bin/X(main+0x47d) [0x80713ed]
> 17: /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xa7bf7455]
> 18: /usr/bin/X(FontFileCompleteXLFD+0x20d) [0x80707d1]
> 
> Fatal server error:
> Caught signal 11.  Server aborting
> 
> (II) UnloadModule: "kbd"
> (II) UnloadModule: "mouse"
> (II) AIGLX: Suspending AIGLX clients for VT switch
> (EE) RADEON(0): RADEONWaitForIdleCP: CP idle -22
> (EE) RADEON(0): Idle timed out, resetting engine...
> (EE) RADEON(0): RADEONWaitForIdleCP: CP reset -22
> (EE) RADEON(0): RADEONWaitForIdleCP: CP start -22
> (EE) RADEON(0): RADEONWaitForIdleCP: CP idle -22
> 
> -
> 
> And the RADEONWaitForIdleCP things are repeated continously.
> 
> Some info about the system
> Card: radeon mobility M7 
> Xserver: 1.5.2
> Distro: Debian
> linux kernel: 2.6.27.5 (but it was the same with 2.6.26)
> radeon driver: 6.9.0+git20081012
> 
> Has anyone ever seen anything like this?

Yes, looks like https://bugzilla.redhat.com/show_bug.cgi?id=445331
(http://bugs.freedesktop.org/show_bug.cgi?id=7128 is probably related,
http://bugs.freedesktop.org/show_bug.cgi?id=18465 possibly).

Basically, the problem is that the (AI)GLX code keeps pointers to
DrawableRec structs of X windows corresponding to GLX windows without
preventing/tracking the destruction of the X windows. So it can happen
that the (AI)GLX code dereferences these pointers after the X window is
already destroyed.

It might be possible for the client (is that kwin for you as well?) to
avoid this problem by making sure that the GLX context is unbound and
destroyed before the X window is destroyed, not sure about that though.


-- 
Earthling Michel Dänzer   |  http://tungstengraphics.com
Libre software enthusiast |  Debian, X and DRI developer

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: New shatter development tree

[Colin Guthrie]

Adam Jackson wrote:
> The primary motivation is working around coordinate limits, yes.  The
> idea is that if you have two CRTCs that can each scan 2k wide, right now
> that implies a total width limit of 2k, because we force them both to
> point to the same physically contiguous allocation.  If you could
> somehow break apart the root window's pixmap, such that rendering to the
> left half went to one piece and rendering to the right half went to the
> other, then you could point one CRTC at each and be happy.
> 
> Thus, "shatter", to break into pieces (which I'll jargonize as "shards"
> from here on in).
> 
> Internally to the server we more or less assume that all pixmaps (and by
> extension, all windows) have a single allocation of pixels behind them.
> You can fix this if you're careful, by creating some pixmaps with _no_
> direct storage, attaching a bunch of shard pixmaps to them, and
> intercepting rendering to the virtual pixmap and re-dispatching it
> against the shards, translating as appropriate.  This works best when
> you enforce a strict separation in your internal data structures between
> the thing you're drawing on and the way in which you're drawing -
> between the Drawable and the GC - because you need the ability to create
> ephemeral rendering contexts but long-lived surfaces.  This requires a
> bit of contortion to work in the face of Render and Xv, but it looks
> doable.  Finally, extending this to DRI requires also shattering the
> back buffer allocations and replaying display lists against each.  Right
> now I'm just working on the 2d parts, but 3d is definitely in the plan.
> 
> This is all not dissimilar to the Xinerama problem, where you have
> multiple GPUs that you want to dispatch rendering against.  Eventually I
> do want to see the xinerama and shatter machinery merged, probably by
> having one super ScreenRec that dispatches its shard rendering against
> other ScreenRecs (as opposed to, say, RANDR shattering, where the shards
> and the virtual are attached to the same ScreenRec).  So there's some
> application to the switchable GPU machines too, since in principle the
> xinerama layer need not dispatch against _both_ shards.
> 
> More technical details:
> 
> http://cgit.freedesktop.org/~ajax/xserver-shatter/tree/doc/shatter.txt?h=shatter-2008&id=c92848a6f2b38a92ef008f74f18c39b11fba0b97

Sounds great!! Good luck. I'll be a happy tester here :)

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Looking for API to possibly implement "mastered image transfer" for xf86-video-savage

[Michel Dänzer]

On Mon, 2008-11-10 at 13:37 -0500, Alex Villací­s Lasso wrote:
> 
> The question is: is there any xserver support that might enable a driver 
> to get pixmap data into either kind of situation? Either get the pixmap 
> into physically contiguous pages and obtain the physical address of the 
> start of data, or pre-copy the pixmap data into AGP memory (allocated by 
> the driver on startup, if necessary)

There isn't any such support in the X server; it would be mostly a
kernel level thing anyway.

> so that the driver does not need to copy it into AGP memory every
> single time.

FWIW, that's what the radeon driver does currently.


-- 
Earthling Michel Dänzer   |  http://tungstengraphics.com
Libre software enthusiast |  Debian, X and DRI developer

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Is there a maintainer for proto/trapproto, lib/libXTrap, app/xtrap, and Xorg XTRAP extension?

[Peter Breitenlohner]

Hi,

while looking through (gcc) compiler warnings I noticed, that the xtrap
headers probably ought to be reorganized.

1. Current status
=

At the moment proto/trapproto installs these headers:

(A) 



(B) 



(C) 

where headers (A+B) are used by lib/libXTrap and app/xtrap,
whereas (A+C) are used by the Xorg XTRAP extension.

Moreover, xtrapdi.h declares the non-prototype function pointer types
typedef int  (*int_function)();
used by the Xorg XTRAP extension, as well as
typedef void (*void_function)();
used by the Xorg XTRAP extension, lib/libXTrap, and app/xtrap.

2. Desirable final status
=

proto/trapproto installs



lib/libXTrap installs



Xorg uses (and possibly installs)
xtrapddmi.h

All of them should eventually use ANSI C prototypes and get rid of
int_function and void_function

3. How to proceed
=

3.1. Move the declarations of int_function and void_function to xtrapddmi.h,
  and copy the declarations of void_function to xtraplib.h.

3.2.1. Move the headers (B) from proto/trapproto to lib/libXTrap
3.2.2. Modify app/xtrap not to use void_function (relatively simple)
3.2.3. Modify lib/libXTrap not to use void_function (relatively simple)
3.2.4. Remove that declaration from xtraplib.h.

3.3.1. Move the header (C) from proto/trapproto to the Xorg XTRAP extension
(to be installed or not), and make sure any old installed version of
 is removed
3.3.2. Modify the Xorg XTRAP extension not to use int_function and
void_function (may be somewhat complicated)
3.3.3. Remove these declarations from xtrapddmi.h.

Regards,
Peter Breitenlohner <[EMAIL PROTECTED]>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Mouse button problems using Logitech NX80

[Matija Šuklje]

Dne torek 11. novembra 2008 je Peter Hutterer napisal(a):
> correct. you could just upgrade to 2.1 RC3 from

Alright, so I upgrated to 2.0.99.3 changed my xorg.conf to look like this:

Identifier  "Mouse"
Driver  "evdev"
#Option "Name"  "Logitech USB Receiver"
Option  "Device""/dev/input/event4"
Option  "Resolution""1000"
#Option "Emulate3Buttons"   "true"
#Option "Buttons"   "9"
Option  "ButtonMapping" "1 0 3 4 5 7 6 2 2"
#Option "ZAxisMapping"  "4 5 7 6"

And the results of thissetting now are:
* scroolling works correctly in both ways now — OK
* in 'KDM' the 8th and 9th button act as the middle one (and there is no 3rd 
button emulation) — OK
* in a KDE session though, the 8th and 9th button act as the left mouse button 
(and for some reason 3rd button emulation works)

This I find quite odd and can't figure out why. I've checked 'kcontrol' in 
case there's a KDE-specific setting somewhere, but didn't find it.


Cheers,
Matija

-- 
gsm: +386 41 849 552
e-mail: [EMAIL PROTECTED]
www: http://matija.suklje.name

aim: hookofsilver
icq: 110183360
jabber/g-talk: [EMAIL PROTECTED]
msn: [EMAIL PROTECTED]
yahoo: matija_suklje
GPG/PGP fingerprint: FB64 FFAF B8DA 5AB5 B18A 98B8 2B68 0B51 0549 D278


signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Status of VA-API or similar

[Nicolas Will]

Hello,

I was just curious about what is happening around the VA-API

http://www.freedesktop.org/wiki/Software/vaapi

Is it something that is still worked on?

Is something else in the pipeline?

H.264 acceleration, among others, would be great with all those digital
HDTV channels coming up.

Nico

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Mouse button problems using Logitech NX80

[Matija Šuklje]

Dne torek 11. novembra 2008 je Steven J Newbury napisal(a):
> On Gentoo, you'll find it in games-util/joystick.

Thanks :)

Cheers,
Matija

-- 
gsm: +386 41 849 552
e-mail: [EMAIL PROTECTED]
www: http://matija.suklje.name

aim: hookofsilver
icq: 110183360
jabber/g-talk: [EMAIL PROTECTED]
msn: [EMAIL PROTECTED]
yahoo: matija_suklje
GPG/PGP fingerprint: FB64 FFAF B8DA 5AB5 B18A 98B8 2B68 0B51 0549 D278


signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg