Does Intel 865G graphics card support gamma correction

2005-06-22 Thread Karthik Ramamoorthy
Hi all,

In my system ie Intel PC with i865G integrated graphics card,
i am not able to do gamma correction. My Linux is SuSE 9.2.
Is it that Intel cards does have XFree86 driver support to
change gamma values.

   How can i do gamma correction in my system. Is it possible in
Intel systems or not?

Regards
Karthik R

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel


Re: DBE on nv, Shape and XAA questions

2005-06-22 Thread Michal Maruška
Mark Vojkovich <[EMAIL PROTECTED]> writes:

> On Sat, 18 Jun 2005, Michal [iso-8859-2] Maru¹ka wrote:
>
>> * Is it correct, that the "nv" driver does not support DBE (double buffer 
>> extension)?
>
>The drivers have nothing to do with DBE extension support.  XFree86
> supports DBE for all hardware whenever you load the "extmod" module.
> DBE is not supported in Xinerama, however.

Thank you for the solution. It was the Option "Xinerama" "true", even if I had
no configuration for the xinerama layout.  Strange that with mga driver DBE
works even with xinerama. Some manpage (the nv?)  should mention this
incompatibility.

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel


libXinerama

2005-06-22 Thread device hda1
Dear Mark,
I'm sorry for sending this email, but I've read in 
http://www.mail-archive.com/devel@xfree86.org/msg07158.html, there was discuss 
about Metacity window, and Manikandan T ask about libXinerama.so.1, and you 
said that you can provide libXinerama.so.1, below was your posting.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Mark Vojkovich
Sent: 07 April 2005 22:56
To: devel@XFree86.Org
Subject: Re: missing libXinerama.so.1 

   It's unfortunate that Metacity has that dependency.  The .so comes
with newer X-servers.  You can try to pull one out of newer X-server
packages.  I can mail you the library alone if want.

Mark.

Is it ok if I ask you to send me libXinerama.so.1 too ?

Thanks in Advance,
Aji

--
Wahai Raja Iblis Datanglah disini ada Linux
(asumsikan disini ada gambar bintang lima terbalik dalam sebuah lingkaran)
Datang ngga dijemput, pulang ngga diantar
(Khan besar mo ko bedeng)
--


-- 
___
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel


Re: SO_KEEPALIVE - a solution for where X servers are shut down?

2005-06-22 Thread Andrew C Aitchison
On Fri, 10 Jun 2005, Nick Hill wrote:

> The problem:
> When running X programs to a remote X server, if the remote X server
> stops being available, the programs which were being displayed often
> stay running. This results in many stale programs running and using
> resources.
> 
> It appears that by default, xlibs opens TCP sockets to remote X servers
> without setting SO_KEEPALIVE.
...
> If this would work, can anyone consider a reason not to enable SO_KEEPALIVE?

I guess it was set this way so that idle clients don't die randomly
just because the network is busy.
Say you are logged on when you go home for the night (I hate it when 
users do that) with important files open in emacs. For a few minutes
during the night the backups saturate the network and emacs dies.

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel


Re: SO_KEEPALIVE - a solution for where X servers are shut down?

2005-06-22 Thread Matthias Scheler
On Fri, Jun 10, 2005 at 04:52:25PM +0100, Nick Hill wrote:
> If the TCP socket is closed by the kernel, will X apps also close,
> thereby freeing redundant resources?

Yes.

> If this would work, can anyone consider a reason not to enable SO_KEEPALIVE?

It might cause problems which e.g. use a notebook as X11 server and
suspend it. Without such a change the X11 clients will survive, with
the change they'll be killed.

The best solution is probably to make that optional.

Kind regards

-- 
Matthias Scheler  http://scheler.de/~matthias/
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel


Re: DBE on nv, Shape and XAA questions

2005-06-22 Thread Mark Vojkovich
On Sat, 18 Jun 2005, Michal [iso-8859-2] Maru?ka wrote:

> * Is it correct, that the "nv" driver does not support DBE (double buffer 
> extension)?

   The drivers have nothing to do with DBE extension support.  XFree86
supports DBE for all hardware whenever you load the "extmod" module.
DBE is not supported in Xinerama, however.

>
>
> * How fast are "Screen to screen bit blits" ?

   Depends on the hardware.  Hardware blits are always significantly
faster than software blits.

>
> I tuned sawfish WM, so that when resizing windows it sets the border window 
> (WM
> decoration) to a suitable window gravity, so it's up to the X server to move 
> it
> correctly (WM does not redraw). I avoided shaped windows.
>
> I use the "mga" driver, so it has "Screen to screen bit blits" XXA call.
>
> Yet, if I resize (in 1 direction) continuously the window, i see the vertical
> line as a staircase line:
>
>
>||
> b  ||
> l  |   |
> a  | ->|
> c  |   |
> k  |  |
>|  |
>
> Any idea if it can be improved?

   Rendering is not synchronized with the screen retrace, so tearing
is expected.

>
> * Shape vs. flickering
>
> if i run xlogo -shape (resize it to make things clear) and move the logo 
> window, i see
> flickering (the window below is obscured and redrawn even outside of the 
> logo).

We you move a window, the uncovered area needs to be redrawn, of
course.  When using the shape extension, exposures are not done down
to the pixel.  For performance reasons, it's exposing bounding boxes,
because every separate exposed rectangle is a additional call back
to the client.


>
> I would likt to know, if "Screen to Screen color expansion" XAA call could be 
> used to
> avoid it.
>

   Everything is already fully accelerated.  Add Option "NoAccel" to
your Section "Device" in the XF86Config file to see what unaccelerated
rendering looks like.


Mark.

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel