Re: What is driverSwapMethod = DRI_HIDE_X_CONTEXT?

2004-10-28 Thread Roland Scheidegger
Jon Smirl wrote:
I just changed DRM to alternative between zero and POLLIN This
will make the DRM poll() function work like the kernel expects it to
and still work with existing X servers. Can someone please get this
incorrect code out of the X server?
I got some mysterious server crashes since some time (week or so), about 
once per day, so it looks like the alternate polling isn't working. Just 
as Felix I got the WaitForSomething(): select: errno=22 error message. 
The corresponding bugzilla entry is here: 
http://freedesktop.org/bugzilla/show_bug.cgi?id=1505.
This is with the radeon DDX (rv250), and Xorg cvs (10 days old currently).
I've switched back to the non-core drm version for now and will see if 
this indeed fixes that crash.

Roland
---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: What is driverSwapMethod = DRI_HIDE_X_CONTEXT?

2004-10-28 Thread Jon Smirl
On Thu, 28 Oct 2004 15:11:26 +0200, Roland Scheidegger
[EMAIL PROTECTED] wrote:
 Jon Smirl wrote:
  I just changed DRM to alternative between zero and POLLIN This
  will make the DRM poll() function work like the kernel expects it to
  and still work with existing X servers. Can someone please get this
  incorrect code out of the X server?
 
 I got some mysterious server crashes since some time (week or so), about
 once per day, so it looks like the alternate polling isn't working. Just
 as Felix I got the WaitForSomething(): select: errno=22 error message.
 The corresponding bugzilla entry is here:
 http://freedesktop.org/bugzilla/show_bug.cgi?id=1505.
 This is with the radeon DDX (rv250), and Xorg cvs (10 days old currently).
 I've switched back to the non-core drm version for now and will see if
 this indeed fixes that crash.

I just changed this to always return the broken response of zero. When
this gets fixed in the Xserver we can use a DRM interface version
number to control returning the correct response. Meanwhile I guess
the kernel developers are going to have to live with Xserver/DRM
making up their own rules for how poll() works.

-- 
Jon Smirl
[EMAIL PROTECTED]


---
This Newsletter Sponsored by: Macrovision 
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate 
today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: What is driverSwapMethod = DRI_HIDE_X_CONTEXT?

2004-10-16 Thread Felix Kühling
Am Mi, den 13.10.2004 schrieb Michel Dänzer um 22:57:
 On Wed, 2004-10-13 at 19:42 +0200, Felix Kühling wrote:
  Am Mi, den 13.10.2004 schrieb Jon Smirl um 18:53:
   I just changed DRM to alternative between zero and POLLIN This
   will make the DRM poll() function work like the kernel expects it to
   and still work with existing X servers. Can someone please get this
   incorrect code out of the X server?
  
  As I mentioned earlier, setting driverSwapMethod to DRI_KERNEL_SWAP
  seems to work for the savage driver. I bet it works for many others too.
  AFAICT this tells the common DRI code not to use the DRM file handle.
  Once this is proven to work with all drivers we could axe the code for
  the other methods.
 
 I doubt it's that simple, e.g. the DDX driver's SwapContext() function
 is only called with DRI_HIDE_X_CONTEXT AFAICT.

[slowly starting to make sense of all this ...]

Right. The default Block and Wakeup handlers only call SwapContext if
DRI_HIDE_X_CONTEXT is set. But a driver can install its own Block and
Wakeup handlers. I think that's what I'm going to do for the Savage
driver. I believe it should work for Radeon (for example) too. The
custom handlers would lock/unlock and call RADEONEnterServer or
RADEONLeaveServer respectively.

If I understand Keith correctly then all the modern drivers don't use
the SIGIO method (kernel notifies Xserver of context switches) any more.
So there is really no need for the full HIDE_X_CONTEXT+SERVER_SWAP
overhead.

-- 
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3  B152 151C 5CC1 D888 E595 |



---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: What is driverSwapMethod = DRI_HIDE_X_CONTEXT?

2004-10-13 Thread Keith Whitwell
Felix Kühling wrote:
While investigating rare Xserver (errno=22 in select) and X client
(losing X connection) crashes that seem to be related to the new
linux-core drm I found this in savage_dri.c and several other DDX
drivers:
   ...driverSwapMethod = DRI_HIDE_X_CONTEXT;
This seems to indicate that the Xserver is somehow involved in direct
rendering buffer swap operations and the driver-independent DRI code
installs a DRM signal handler for it. I changed it to DRI_KERNEL_SWAP in
the savage driver and have not got any crashes since. I'm going to
stress this system a bit more tomorrow. GL apps still work, as expected
since in the savage driver the kernel is currently not involved in
buffer swaps. It's all done client side.
This is all to do with the original drm design providing a number of different 
ways to implement context switching.  All the modern drivers use one, I 
believe that it was DRI_HIDE_X_CONTEXT, though the names are quite confusing. 
 Basically there were provisions to allow context switches to be handled in 
the kernel, in the 3d driver or in the X server.

I think the reason that you are experiencing failures is because the X server 
is trying to read or poll the drm filehandle, but Jon has recently changed the 
behaviour of that filehandle to return an error on those operations, rather 
than indicating that no bytes are pending.

Let me stress that in most drivers there is no need for the X server to be 
looking at this filehandle at all, but the code which does so is widely 
distributed and this change to the DRM will break it.

Keith
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: What is driverSwapMethod = DRI_HIDE_X_CONTEXT?

2004-10-13 Thread Jon Smirl
On Wed, 13 Oct 2004 10:13:50 +0100, Keith Whitwell
[EMAIL PROTECTED] wrote:
 Felix Kühling wrote:
 I think the reason that you are experiencing failures is because the X server
 is trying to read or poll the drm filehandle, but Jon has recently changed the
 behaviour of that filehandle to return an error on those operations, rather
 than indicating that no bytes are pending.
 
 Let me stress that in most drivers there is no need for the X server to be
 looking at this filehandle at all, but the code which does so is widely
 distributed and this change to the DRM will break it.

Is it the poll() call that is the problem? I can set it back to
returning zero. The kernel people are saying this is wrong and are
pushing me to have it return (POLLIN | POLLOUT | POLLRDNORM |
POLLWRNORM) which is the correct return for an unimplemented poll
function.

Should we increment the DRM version in the set_version call and then
change the return conditionally and fix the X server? Or is there a
way to make this work on existing X servers with the correct return?

I don't use the function so I'm just implementing what people tell me to do.

-- 
Jon Smirl
[EMAIL PROTECTED]


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: What is driverSwapMethod = DRI_HIDE_X_CONTEXT?

2004-10-13 Thread Keith Whitwell
Jon Smirl wrote:
On Wed, 13 Oct 2004 10:13:50 +0100, Keith Whitwell
[EMAIL PROTECTED] wrote:
Felix Kühling wrote:
I think the reason that you are experiencing failures is because the X server
is trying to read or poll the drm filehandle, but Jon has recently changed the
behaviour of that filehandle to return an error on those operations, rather
than indicating that no bytes are pending.
Let me stress that in most drivers there is no need for the X server to be
looking at this filehandle at all, but the code which does so is widely
distributed and this change to the DRM will break it.

Is it the poll() call that is the problem? I can set it back to
returning zero. The kernel people are saying this is wrong and are
pushing me to have it return (POLLIN | POLLOUT | POLLRDNORM |
POLLWRNORM) which is the correct return for an unimplemented poll
function.
In the very beginning, shared code in the X server listened to this fd, and 
shared code in the DRM existed to write to this fd, at the possible request of 
device-dependent DRM code.  The first DRM driver, the gamma, used this 
mechanism for context switching.  But no other DRM driver except perhaps ffb 
ever has.

About 18 months ago, I recognized this and pushed the shared code into the 
gamma driver, and removed the poll() and read() functions from drm_fops.h. 
Within the day I recognized that the X server continued to examine the fd, and 
that there was a need to restore empty poll() and read() functions.  Now that 
the gamma driver is dead, maybe we can go about pulling that behaviour out of 
the X server shared code as well.  But right now, you have a situation where 
everybody running a DRI-enabled X server is dependent on the poll() (and maybe 
read()) function behaving in the way it always has.

So, it's not really an unimplemented poll() function, but the 
backwards-compatible ghost of a real communications channel which is still 
polled, but never written to.

Keith
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: What is driverSwapMethod = DRI_HIDE_X_CONTEXT?

2004-10-13 Thread Jon Smirl
On Wed, 13 Oct 2004 16:39:27 +0100, Keith Whitwell
[EMAIL PROTECTED] wrote:
 So, it's not really an unimplemented poll() function, but the
 backwards-compatible ghost of a real communications channel which is still
 polled, but never written to.

One way to fix this would be to alternately return (POLLIN | POLLOUT |
POLLRDNORM |  POLLWRNORM) and zero.  For a normal poll function zero
means that data is not ready and to keep on polling. If we alternate
between the two a correct polling program would get the zero, and then
poll again and get POLLIN.. and work. If X tries the poll function it
will get POLLIN.., retry and get zero, so it should work too.

Will the current X code retry on a non-zero return?
Can we fix the X server to remove this code in the future?
Or fix the X server to set a higher interface number and change
behavior based on the interface number?

Right now I removed the polling code from DRM and the OS defaults took over. 

-- 
Jon Smirl
[EMAIL PROTECTED]


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: What is driverSwapMethod = DRI_HIDE_X_CONTEXT?

2004-10-13 Thread Felix Kühling
Am Mi, den 13.10.2004 schrieb Jon Smirl um 18:53:
 I just changed DRM to alternative between zero and POLLIN This
 will make the DRM poll() function work like the kernel expects it to
 and still work with existing X servers. Can someone please get this
 incorrect code out of the X server?

As I mentioned earlier, setting driverSwapMethod to DRI_KERNEL_SWAP
seems to work for the savage driver. I bet it works for many others too.
AFAICT this tells the common DRI code not to use the DRM file handle.
Once this is proven to work with all drivers we could axe the code for
the other methods.

Regards,
  Felix

-- 
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3  B152 151C 5CC1 D888 E595 |



---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: What is driverSwapMethod = DRI_HIDE_X_CONTEXT?

2004-10-13 Thread Keith Whitwell
Felix Kühling wrote:
Am Mi, den 13.10.2004 schrieb Jon Smirl um 18:53:
I just changed DRM to alternative between zero and POLLIN This
will make the DRM poll() function work like the kernel expects it to
and still work with existing X servers. Can someone please get this
incorrect code out of the X server?

As I mentioned earlier, setting driverSwapMethod to DRI_KERNEL_SWAP
seems to work for the savage driver. I bet it works for many others too.
I'd rather see the whole context-switching code in the shared code given a 
good shaking out  fixed properly.  Ie. we should apply the same knife to the 
shared DRI code that has been cutting the dead flesh out of DRM.

AFAICT this tells the common DRI code not to use the DRM file handle.
Once this is proven to work with all drivers we could axe the code for
the other methods.
But it won't fix the code that's out there now, which is the backwards 
compatibility concern.

Keith
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: What is driverSwapMethod = DRI_HIDE_X_CONTEXT?

2004-10-13 Thread Michel Dänzer
On Wed, 2004-10-13 at 19:42 +0200, Felix Khling wrote:
 Am Mi, den 13.10.2004 schrieb Jon Smirl um 18:53:
  I just changed DRM to alternative between zero and POLLIN This
  will make the DRM poll() function work like the kernel expects it to
  and still work with existing X servers. Can someone please get this
  incorrect code out of the X server?
 
 As I mentioned earlier, setting driverSwapMethod to DRI_KERNEL_SWAP
 seems to work for the savage driver. I bet it works for many others too.
 AFAICT this tells the common DRI code not to use the DRM file handle.
 Once this is proven to work with all drivers we could axe the code for
 the other methods.

I doubt it's that simple, e.g. the DDX driver's SwapContext() function
is only called with DRI_HIDE_X_CONTEXT AFAICT.


-- 
Earthling Michel Dnzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel