[This e-mail has been automatically generated.]
http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=48
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Platform| |All
------- Additional Comments From [EMAIL PROTECTED] 2003-03-26 16:48 -------
Mark Vojkovich pointed out the user error in private mail: the mode
switch is implemented as a protocol command, and the subsequent exit
from main() prevents the command from being transmitted at all.
Instead, let me ammend this to: XF86VidModeSwitchToMode should do an
implicit flush. A reasonable use case for this functionality is a
single-purpose watch dog program that resets the video mode upon
(unexpected) termination of a full screen client. Forcing such
clients to call X{Sync|Flush|CloseDisplay} is just asking for
confusion.
I am not the first to discover this issue; of the cases I found on the
web, none included a correct diagnosis and most simply used the "call
it twice" therapy.
Additionally, the implementation as an async command prevents the call
from being able to return an indication of success. It may be that
all drivers and all hardware will be able to support all advertised
video modes under all possible conditions. But I strongly suspect
this won't always be the case (think of the case of an OpenGL client
with a locked, process-mapped memory region a-la
ARB_vertex_buffer_object that fragments the framebuffer, preventing
some modes from finding continguous space). Applications using this
API are likely to want to know that it succeeded.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
