Re: CVS XFree (savage driver) xsuite failures
David Dawes wrote: Where does the LED state get resynced with the DDX? The only place that I see the LED state synced with the DDX is at init time. If I disable XKB, 'xset q' doesn't report changes to the real LED state. Yes. But I think it's rather a bug. Note that by deafult (without XLeds option in the config file) all LEDs are protected from changes by applications and the core protocol doesn't provide any way to get real LEDs state. Thus the XGetKeyboardControl request just reflects attempts (unsuccessful with deafult settings) of some applications to change the LEDs state. Those tests work OK for me now if I disable XKB. I don't think it is unreasonable to do the core protocol tests with XKB disabled. I agree. It would be good to add such suggestion into xsuite README. BTW, the fix for this regression is very simple. We just have to remove one line in dix/devices.c where the LEDs mask field of the keyboard controls structure is being reloaded with the actual LEDs state. The tests will be passed with success. But there will not be any way (in the core protocol) to know the real state of LEDs. It is being loaded with the XKB's LED state, isn't it? It is. Without XKB Xserver doesn't keep real LED state. On the other hand the test itself could be changed. One way is to make it XKB-aware and make it set the needed flag (that turns the XLookupString behavior to the 'core protocol like' one). Another way is don't use the Shift modifier (that can be 'eaten' under some circumstance) there. All other modifiers (except Caps) would be interpreted equaly in both (with/without XKB) cases. That sounds reasonable to me. It would also be nice to add some XKB tests to the test suite. I agree. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS XFree (savage driver) xsuite failures
On Mon, Jan 26, 2004 at 08:57:34PM +0600, Ivan Pascal wrote: Those tests work OK for me now if I disable XKB. I don't think it is unreasonable to do the core protocol tests with XKB disabled. I agree. It would be good to add such suggestion into xsuite README. I've updated the notes there, and the info printed by the run.sh script. I'll upload this and some other small updates as version 4.0.6 of our distribution of xtest (ftp://ftp.xfree86.org/pub/XFree86/xtest/). David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS XFree (savage driver) xsuite failures
David Dawes wrote: On Tue, Jan 20, 2004 at 10:32:12PM +0100, Nicolas Joly wrote: On Tue, Jan 20, 2004 at 10:28:16AM -0800, Mark Vojkovich wrote: On Tue, 20 Jan 2004, Nicolas Joly wrote: If your lines are correct, you should be able to run: http://www.xfree86.org/~mvojkovi/linetest.c without artifacts. The lines seems wrong as i do see artifacts when running the program with zero width lines (works fine for w0). If you add to the Section "Device" of the XF86Config file: Option "XaaNoSolidTwoPointLine" that will force the XAA to only use the driver's Bresenham line export. Does that change the behavior? Yes ! I do not see the problem with the linetest program anymore. Will check (in a day or two) with the testsuite, and report. So it looks like the attached patch should be committed? Yes, I would concur with this. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc.
Re: CVS XFree (savage driver) xsuite failures
On Tue, Jan 20, 2004 at 10:32:12PM +0100, Nicolas Joly wrote:
On Tue, Jan 20, 2004 at 10:28:16AM -0800, Mark Vojkovich wrote:
If you add to the Section Device of the XF86Config file:
Option XaaNoSolidTwoPointLine
that will force the XAA to only use the driver's Bresenham line
export. Does that change the behavior?
Yes ! I do not see the problem with the linetest program anymore.
Will check (in a day or two) with the testsuite, and report.
I just ran the testsuite again. Here follow the diff for the failing
tests :
[EMAIL PROTECTED] [~] diff fail.24.old fail.24.new
0a1,3
Tests for XOpenDisplay
Test 3: FAIL
Test 4: FAIL
11,16d13
Tests for XDrawLine
Test 52: FAIL
Tests for XDrawLines
Test 57: FAIL
Tests for XDrawSegments
Test 53: FAIL
24,25d20
Tests for ChangeHosts
Test 1: FAIL
With XaaNoSolidTwoPointLine option set, XDraw{Line,Lines,Segements}
tests are successful.
For the `ChangeHosts' failure, i changed the `XT_DISPLAYHOST'
testsuite variable from `localhost' to `cixy.dial.pasteur.fr'.
This test succeded, but 2 new failed ... XOpenDisplay. Without network
connection, i think this is expected :
Tests for XOpenDisplay
Test 3: FAIL
XOpenDisplay() returned NULL with argument cixy.dial.pasteur.fr:0.0.
Test 4: FAIL
XOpenDisplay() returned NULL with argument cixy.dial.pasteur.fr:0.
--
Nicolas Joly
Biological Software and Databanks.
Institut Pasteur, Paris.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: CVS XFree (savage driver) xsuite failures
On Sun, Jan 25, 2004 at 05:15:11PM +0100, Nicolas Joly wrote:
On Tue, Jan 20, 2004 at 10:32:12PM +0100, Nicolas Joly wrote:
On Tue, Jan 20, 2004 at 10:28:16AM -0800, Mark Vojkovich wrote:
If you add to the Section Device of the XF86Config file:
Option XaaNoSolidTwoPointLine
that will force the XAA to only use the driver's Bresenham line
export. Does that change the behavior?
Yes ! I do not see the problem with the linetest program anymore.
Will check (in a day or two) with the testsuite, and report.
I just ran the testsuite again. Here follow the diff for the failing
tests :
[EMAIL PROTECTED] [~] diff fail.24.old fail.24.new
0a1,3
Tests for XOpenDisplay
Test 3: FAIL
Test 4: FAIL
11,16d13
Tests for XDrawLine
Test 52: FAIL
Tests for XDrawLines
Test 57: FAIL
Tests for XDrawSegments
Test 53: FAIL
24,25d20
Tests for ChangeHosts
Test 1: FAIL
With XaaNoSolidTwoPointLine option set, XDraw{Line,Lines,Segements}
tests are successful.
Looks good. I'll commit the patch I posted here last night.
For the `ChangeHosts' failure, i changed the `XT_DISPLAYHOST'
testsuite variable from `localhost' to `cixy.dial.pasteur.fr'.
This test succeded, but 2 new failed ... XOpenDisplay. Without network
connection, i think this is expected :
Tests for XOpenDisplay
Test 3: FAIL
XOpenDisplay() returned NULL with argument cixy.dial.pasteur.fr:0.0.
Test 4: FAIL
XOpenDisplay() returned NULL with argument cixy.dial.pasteur.fr:0.
I don't think this indicates a real problem.
David
--
David Dawes
developer/release engineer The XFree86 Project
www.XFree86.org/~dawes
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: CVS XFree (savage driver) xsuite failures
On Sat, 24 Jan 2004, David Dawes wrote: On Tue, Jan 20, 2004 at 10:32:12PM +0100, Nicolas Joly wrote: On Tue, Jan 20, 2004 at 10:28:16AM -0800, Mark Vojkovich wrote: On Tue, 20 Jan 2004, Nicolas Joly wrote: If your lines are correct, you should be able to run: http://www.xfree86.org/~mvojkovi/linetest.c without artifacts. The lines seems wrong as i do see artifacts when running the program with zero width lines (works fine for w0). If you add to the Section Device of the XF86Config file: Option XaaNoSolidTwoPointLine that will force the XAA to only use the driver's Bresenham line export. Does that change the behavior? Yes ! I do not see the problem with the linetest program anymore. Will check (in a day or two) with the testsuite, and report. So it looks like the attached patch should be committed? David I think so. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS XFree (savage driver) xsuite failures
On Wed, Jan 21, 2004 at 12:06:50PM +0600, Ivan Pascal wrote:
Hello,
Mark Vojkovich wrote:
On Mon, 19 Jan 2004, David Dawes wrote:
Tests for XChangeKeyboardControl
Test 9: FAIL
Test 10: FAIL
That has been showing up for a while. It should be followed up.
That's been showing up for a couple years. It's a regression.
I think the tests are incorrect. Both tests try to set keyboard LEDs (using
XChangeKeyboardControl) then read the LEDs state (XGetKeyboardControl) and
compare values. The difference between the tests is that the first one tries
to change some of LEDs (uses some mask) and the second one tries to set all
LEDs together (without specifying a particular LED number).
But some LEDs can be protected from their change by client application and
reflect keyboard state only.
The man about {Change|Get}KeyboardControl tells:
XChangeKeyboardControl - ...the state of that leds is changed, if possible..
XGetKeyboardControl - ...each bit set to 1 in led_mask indicates an LED that
is lit (Note if possible and an LED that is lit.)
I understand it as Get returns the actual state of LEDs, those that are not
protected and were changed by Change and those that are protected but are
switched on reflecting the keyboard state.
But the tests, obviously, are written in assumption that Get should return the
LED state exactly as it was written into keyboard by Change call. It means all
LEDs should be unprotected (it is not by default) or the keyboard control
structure keeps values written by XChangeKeyboardControl call(s) and at the
XGetKeyboardControl request just returns this record instead of real state
of LEDs.
Where does the LED state get resynced with the DDX? The only place that
I see the LED state synced with the DDX is at init time. If I disable
XKB, 'xset q' doesn't report changes to the real LED state.
Those tests work OK for me now if I disable XKB. I don't think it is
unreasonable to do the core protocol tests with XKB disabled.
BTW, the fix for this regression is very simple. We just have to remove
one line in dix/devices.c where the LEDs mask field of the keyboard controls
structure is being reloaded with the actual LEDs state. The tests will be
passed with success. But there will not be any way (in the core protocol)
to know the real state of LEDs.
It is being loaded with the XKB's LED state, isn't it?
Tests for XRebindKeysym
Test 1: FAIL
The XRebindKeysym failure goes away if XKB is disabled.
Yes, it's a XKB problem/feature.
It is a feature. :)
This problem can be fixed easy too with 'one word patch'. But there is one
unclear thing there.
The RebindKeysym mechanism allows to tie any string to a keysym or a combination
of keysym and a set of modifiers. The binding itself works well, the problem
is the modifiers set interpretation.
For example, we have a key with two keysyms [a A] and want to bind two different
strings to combiantions Alt+a and Alt+A. How should we specify the second
combination - Alt + 'A', Alt + Shift + 'a' or Alt + Shift + 'A'?
The core protocol's assumes the third variant, i.e. takes the keysym figured
out with taking in account the Shift modifier but also checks all modifiers
obtained from the key event.
But the XKB-aware XLookupString 'consumes' all modifiers used at the keysym
choosing and hide them from the routine that checks string_to_key bindins,
i.e. it expects that the combiantion is just Alt + 'A'.
BTW, this behavour can be swithed on/off with a special 'client side XKB' flag
but by default XLookupString 'eats' consumed modifiers.
Thus the problem is what modifiers set should the bindings check routine use.
Shoud it always be the original 'state' field from the key event or the
consumed modifiers may be removed from a consideration. If we require there
a full compatibility with the core protocol the answer is obvious. But some
calls in XKB-aware Xlib already have differences from core protocol ones.
And the first form of that combination seems to me more logical (IMHO,
of course).
Side note: I wonder if anybody (anything) uses this 'rebind keysym' feature
anywhere.
On the other hand the test itself could be changed. One way is to make it
XKB-aware and make it set the needed flag (that turns the XLookupString
behavior to the 'core protocol like' one). Another way is don't use the Shift
modifier (that can be 'eaten' under some circumstance) there. All other
modifiers (except Caps) would be interpreted equaly in both (with/without XKB)
cases.
That sounds reasonable to me. It would also be nice to add some XKB tests
to the test suite.
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: CVS XFree (savage driver) xsuite failures
On Tue, 20 Jan 2004, Nicolas Joly wrote: If your lines are correct, you should be able to run: http://www.xfree86.org/~mvojkovi/linetest.c without artifacts. The lines seems wrong as i do see artifacts when running the program with zero width lines (works fine for w0). If you add to the Section Device of the XF86Config file: Option XaaNoSolidTwoPointLine that will force the XAA to only use the driver's Bresenham line export. Does that change the behavior? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS XFree (savage driver) xsuite failures
Hello,
Mark Vojkovich wrote:
On Mon, 19 Jan 2004, David Dawes wrote:
Tests for XChangeKeyboardControl
Test 9: FAIL
Test 10: FAIL
That has been showing up for a while. It should be followed up.
That's been showing up for a couple years. It's a regression.
I think the tests are incorrect. Both tests try to set keyboard LEDs (using
XChangeKeyboardControl) then read the LEDs state (XGetKeyboardControl) and
compare values. The difference between the tests is that the first one tries
to change some of LEDs (uses some mask) and the second one tries to set all
LEDs together (without specifying a particular LED number).
But some LEDs can be protected from their change by client application and
reflect keyboard state only.
The man about {Change|Get}KeyboardControl tells:
XChangeKeyboardControl - ...the state of that leds is changed, if possible..
XGetKeyboardControl - ...each bit set to 1 in led_mask indicates an LED that
is lit (Note if possible and an LED that is lit.)
I understand it as Get returns the actual state of LEDs, those that are not
protected and were changed by Change and those that are protected but are
switched on reflecting the keyboard state.
But the tests, obviously, are written in assumption that Get should return the
LED state exactly as it was written into keyboard by Change call. It means all
LEDs should be unprotected (it is not by default) or the keyboard control
structure keeps values written by XChangeKeyboardControl call(s) and at the
XGetKeyboardControl request just returns this record instead of real state
of LEDs.
BTW, the fix for this regression is very simple. We just have to remove
one line in dix/devices.c where the LEDs mask field of the keyboard controls
structure is being reloaded with the actual LEDs state. The tests will be
passed with success. But there will not be any way (in the core protocol)
to know the real state of LEDs.
Tests for XRebindKeysym
Test 1: FAIL
The XRebindKeysym failure goes away if XKB is disabled.
Yes, it's a XKB problem/feature.
It is a feature. :)
This problem can be fixed easy too with 'one word patch'. But there is one
unclear thing there.
The RebindKeysym mechanism allows to tie any string to a keysym or a combination
of keysym and a set of modifiers. The binding itself works well, the problem
is the modifiers set interpretation.
For example, we have a key with two keysyms [a A] and want to bind two different
strings to combiantions Alt+a and Alt+A. How should we specify the second
combination - Alt + 'A', Alt + Shift + 'a' or Alt + Shift + 'A'?
The core protocol's assumes the third variant, i.e. takes the keysym figured
out with taking in account the Shift modifier but also checks all modifiers
obtained from the key event.
But the XKB-aware XLookupString 'consumes' all modifiers used at the keysym
choosing and hide them from the routine that checks string_to_key bindins,
i.e. it expects that the combiantion is just Alt + 'A'.
BTW, this behavour can be swithed on/off with a special 'client side XKB' flag
but by default XLookupString 'eats' consumed modifiers.
Thus the problem is what modifiers set should the bindings check routine use.
Shoud it always be the original 'state' field from the key event or the
consumed modifiers may be removed from a consideration. If we require there
a full compatibility with the core protocol the answer is obvious. But some
calls in XKB-aware Xlib already have differences from core protocol ones.
And the first form of that combination seems to me more logical (IMHO,
of course).
Side note: I wonder if anybody (anything) uses this 'rebind keysym' feature
anywhere.
On the other hand the test itself could be changed. One way is to make it
XKB-aware and make it set the needed flag (that turns the XLookupString
behavior to the 'core protocol like' one). Another way is don't use the Shift
modifier (that can be 'eaten' under some circumstance) there. All other
modifiers (except Caps) would be interpreted equaly in both (with/without XKB)
cases.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: CVS XFree (savage driver) xsuite failures
Mark Vojkovich wrote: On Mon, 19 Jan 2004, David Dawes wrote: n Mon, Jan 19, 2004 at 10:11:53PM +0100, Nicolas Joly wrote: Tests for XDrawLine Test 52: FAIL Tests for XDrawLines Test 57: FAIL Tests for XDrawSegments Test 53: FAIL Those three are real. Does the Savage hardware really have a Bresenham line interface? If so, why is it providing the TwoPointLine interface? Probably inexperience on the part of the author. When I was working on the driver, it wasn't obvious to me when one would be preferable to the other, so I added both. The TwoPointLine routine just converts to Bresenham. If XAA does that for me, then it's silly to support both. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS XFree (savage driver) xsuite failures
On Mon, 19 Jan 2004, Tim Roberts wrote: Mark Vojkovich wrote: On Mon, 19 Jan 2004, David Dawes wrote: n Mon, Jan 19, 2004 at 10:11:53PM +0100, Nicolas Joly wrote: Tests for XDrawLine Test 52: FAIL Tests for XDrawLines Test 57: FAIL Tests for XDrawSegments Test 53: FAIL Those three are real. Does the Savage hardware really have a Bresenham line interface? If so, why is it providing the TwoPointLine interface? Probably inexperience on the part of the author. When I was working on the driver, it wasn't obvious to me when one would be preferable to the other, so I added both. The TwoPointLine routine just converts to Bresenham. If XAA does that for me, then it's silly to support both. XAA does it for you. The TwoPointLine hooks were added for hardware that didn't support Bresenham lines. It looks like the TwoPointLine function provided by the savage driver doesn't handle the endpoint correctly. Even with the Bresenham interface you should compare the lines with linetest.c to see if you need to set the miSetZeroLineBias (like the nv driver does) in order to make the HW and SW lines match. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS XFree (savage driver) xsuite failures
On Mon, Jan 19, 2004 at 03:11:17PM -0800, Mark Vojkovich wrote: On Mon, 19 Jan 2004, David Dawes wrote: On Mon, Jan 19, 2004 at 10:11:53PM +0100, Nicolas Joly wrote: Just a small summary with 16 tests failues : Tests for XDrawArc Test 42: FAIL Test 63: FAIL Test 66: FAIL Test 73: FAIL Tests for XDrawArcs Test 45: FAIL Test 66: FAIL Test 69: FAIL Test 76: FAIL The arc failures here look like the expected ones. Yes, those are waived. Tests for XDrawLine Test 52: FAIL Tests for XDrawLines Test 57: FAIL Tests for XDrawSegments Test 53: FAIL Those three are real. Does the Savage hardware really have a Bresenham line interface? If so, why is it providing the TwoPointLine interface? If your lines are correct, you should be able to run: http://www.xfree86.org/~mvojkovi/linetest.c without artifacts. The lines seems wrong as i do see artifacts when running the program with zero width lines (works fine for w0). Tests for XChangeKeyboardControl Test 9: FAIL Test 10: FAIL That has been showing up for a while. It should be followed up. That's been showing up for a couple years. It's a regression. Tests for XKillClient Test 2: FAIL I see the occasional XKillClient fail, but haven't been able to reproduce it reliably. I'm not sure if it is a real bug, or a flaw in the test. I've never seen that one. Tests for XRebindKeysym Test 1: FAIL The XRebindKeysym failure goes away if XKB is disabled. Yes, it's a XKB problem/feature. Tests for ChangeHosts Test 1: FAIL Maybe you didn't set the hostname correctly for the test? Looks like a test configuration error. It was setup to `localhost'. This machine has no real network access (just a 28.8k ppp line) ... Will try again with a real name. -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
