Re: [Xpert]Re: Proposal for mouse speed & acceleration settings

[Michael Toomim]

[EMAIL PROTECTED] wrote:

You keep saying that the resolution can't be changed without editing the
XF86Config file, but the XFree86-Misc extension has made it possible for
years to change that setting on the fly.  It's just a matter of having
a client to interface to that extension and there are a few available,
such as the xmseconfig program that used to be distributed with XFree86.

xset does use the XFree86-Misc extension, but only for changing keyboard
settings.  There's no reason it couldn't be changed to do the same for
the mouse.


That's awesome.  That's exactly what I've been looking for.  I'll look 
into it, and if all works out, I'll forward this information to the 
Gnome folks to get it implemented in something user-visible.

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: Proposal for mouse speed & acceleration settings

[Michael Toomim]

[EMAIL PROTECTED] wrote:


You keep saying that the resolution can't be changed without editing the
XF86Config file, but the XFree86-Misc extension has made it possible for
years to change that setting on the fly.  It's just a matter of having
a client to interface to that extension and there are a few available,
such as the xmseconfig program that used to be distributed with XFree86.

xset does use the XFree86-Misc extension, but only for changing keyboard
settings.  There's no reason it couldn't be changed to do the same for
the mouse.


There's one problem:

   The following option will set the mouse device resolution to N counts
   per inch, if possible:

  Option"Resolution"   "N"

   Not all mice and OSs can support this option.  This option can be set
   in the XF86Setup program.

Does anyone know where I can find out which mice and/or OS's don't 
support the resolution parameter?  Does anyone know why this can't be 
supported universally?  Even if it uses some hardware/os-specific 
feature, it seems like it shouldn't be too hard to emulate for the 
general case...

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: Proposal for mouse speed & acceleration settings

[Michael Toomim]

J. Imlay wrote:


But lambasting people for commenting there opinions on this matter as
being off topic (even if they are) doesn't get any of us anywhere.


Wow.  I didn't think I was "lambasting" Craig.

Craig, I sincerely apologize if I offended you.  I *really* didn't mean 
it to come off that way.  It just seemed like we were talking about 
different things.

Can someone explain to me how what I said was offensive?

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: Patches in limbo - was Re: [Xpert]Re: Proposal for mouse speed & acceleration settings

[Georgina O Economou]

At 11:49 AM 11/2/2002 -0500, you wrote:

On Sat, Nov 02, 2002 at 10:31:10AM +, Stephen Davies wrote:

>So those who send patches should expect some feedback or questions as to
>our code.
>
>I submitted a tdfx driver patch on 7th Oct:
>
>> Your submission to <[EMAIL PROTECTED]> has been assigned the
>> sequence number A.1297.
>
>I would have expected some sort of reply, perhaps one of:
>
> - patch accepted
> - send your patch to xx@yy, maintainer of the tdfx driver
> - we don't understand and won't apply - explain why you do ...
>
>In my case the tdfx driver isn't used so much anymore, less so the XVideo
>support that the patch improves.  Nevertheless, it seems selfish to keep
>the change to myself.

All patch submissions to XFree86 are welcome, but the only guarantee
you get when making a submission is that someone will look at it and
either review it or find someone else to review it.

There is no guarantee about when that will happen, but our goal is that
all submissions received in time for the next release will be reviewed
before that release is finalised.  It's unreasonable to expect the
volunteers who review submissions to do so on your timetable.  Until
it's reviewed, all we can tell you is that we received it and that it's
in our queue (that's what the automated reply does).

Once a submission is reviewed, any of the following may happen:

  1. submission found to be a duplicate, or problem already fixed
  2. committed with or without changes
  3. submitter contacted for further information
  4. held for further review
  5. rejected

For case 1, you probably won't hear anything back.  There's an assumption
that you're following the relevant area of the XFree86 development code,
so you'll already know if the problem you submitted a fix for has since
been fixed.

For case 2, you'll see that the submission has been committed via the
cvs-commit list (http://www.xfree86.org/mailman/listinfo/cvs-commit),
which is archived.  You can also look at the changelog extract on our
web site (http://www.xfree86.org/cvs/changes.html), which is updated
automatically at frequent intervals.  Both your name and the number
assigned to your submission should appear in the commit message and
changelog entry.

In cases 3 and 5 you should be contacted via email.  In case 4 it depends
on the further review.

David
--
David Dawes
Release Engineer/Architect  The XFree86 Project
www.XFree86.org/~dawes



You can also go to www.xfree86.org/support.html and search via the Google 
box the
whole site for your name & see if it's committed.  If you have a question 
about
the commit I would recommend posting it here as cvs commit is an announce only
list.

G


___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: Proposal for mouse speed & acceleration settings

[Michael Toomim]

Craig Carey wrote:


The XFree86 mouse deceleration function gets dx,dy integers that are
small integers in between -1 and +1 quite often. Whatever the function
("formula") was, it could be replaced with these two without much change:

  dx' = k1 * dx * (+1 if dx > 0 else -1)
  dx' = k2 * dx

 [dx is a C int, dx' is real that is added to a real sum and then
 later converted into a screen pixel position]


I think we're miscommunicating here.  My issue has nothing to do with 
problems with small integers.  I just want to be able to control the 
mouse speed (not acceleration) with xset.

Since these two issues are orthogonal, let's try to keep them in 
separate threads.

Michael



___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Re: Proposal for mouse speed & acceleration settings

[joe]

 
> Here's what I'm trying to get at:  I think that the constant multiplier 
> should be settable with xset, instead of requiring one to modify the 
> Resolution option in XF86Config.
[...]
> This setup works really well for me!  The only problem is that it was a 
> bitch to figure out the right values for Resolution and n/d (the 
> exponent), since you have to restart X and modify XF86Config every time 
> I wanted to change the constant multiplier.

You keep saying that the resolution can't be changed without editing the
XF86Config file, but the XFree86-Misc extension has made it possible for
years to change that setting on the fly.  It's just a matter of having
a client to interface to that extension and there are a few available,
such as the xmseconfig program that used to be distributed with XFree86.

xset does use the XFree86-Misc extension, but only for changing keyboard
settings.  There's no reason it couldn't be changed to do the same for
the mouse.


___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Re: Proposal for mouse speed & acceleration settings

[Soeren Sandmann]

Michael Toomim <[EMAIL PROTECTED]> writes:

> The issue disappeared from the mailing list, but I had some discussion
> offline with Joe Krahn about it after the mailing list posts that you
> saw.  During that discussion, I communicated with the woman who
> researched mouse acceleration algorithms at Apple, and she told me
> what algorithm Apple used and what her methodology was to come up with
> the algorithm.  

That is interesting. Could you say more about what she did?

> So between the first two options, my proposal retains backwards
> compatibility and Soeren's gives it up.  Personally, I'd prefer to
> give up backwards compatibility, as I don't believe there is anybody
> who actually *prefers* the threshold-multipler acceleration.  But a
> safer route might be to introduce the option first, and then to phase
> it out slowly as people and desktops begin to support it.

A fourth option would be to create a new extension that would allow
the mouse acceleration to be controlled in detail. From searching on
Google it appears you can do this on Windows XP. (I am not necessarily
suggesting it is a good idea).

Søren
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: Proposal for mouse speed & acceleration settings

[Michael Toomim]

David Dawes wrote:


I think the problem in this particular case is lack of agreement about
the nature of the pointer accleration problem and/or its solution.  If
those interested in solving the problem can discuss it here and come to
some agreement on what the true nature of the problem is, and come up
with a fix that solves it, then the code will get changed.  Churning
the code by committing each personal preference solution that gets
submitted doesn't solve the problem (and that's how I'd characterise
most of the submissions that actually contained patches that I've seen
on this topic so far).

David


Sounds like a good plan.

How about this:  I think that the polynomial function, when given good 
values for "Resolution" and "exponent", solves all the mouse 
acceleration problems that people have been complaining about.  The real 
problem that I see is that it's hard to find good parameters (and that 
none of it is documented).

So, could everyone interested try playing with the power-function 
version of the mouse acceleration algorithm (like I explained in my 
previous post) and find good parameters for "Resolution" and the power 
function's N/D exponent?  If it's possible to get a good acceleration 
function using specific values of these parameters, we can work on 
finally solving this issue by making it easy to modify those parameters.

BTW, be sure that that you're setting threshold to zero -- else you will 
be using the 2-step threshold-multiplier version of the acceleration 
algorithm (which sucks no matter what parameters you give it).

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: Proposal for mouse speed & acceleration settings

[Michael Toomim]

J. Imlay wrote:


But lambasting people for commenting there opinions on this matter as
being off topic (even if they are) doesn't get any of us anywhere.


Wow.  I didn't think I was "lambasting" Craig.

Craig, I sincerely apologize if I offended you.  I *really* didn't mean 
it to come off that way.  It just seemed like we were talking about 
different things.

Can someone explain to me how what I said was offensive?

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: Proposal for mouse speed & acceleration settings

[Michael Toomim]

J. Imlay wrote:

I am just a casual reader on this list so I could be entirly wrong about
all this.

I've read the thread that you started last spring, and I've been following
this one, and I sympathize with you on the problems with the acceleration
in X (it's down right unusable IMHO) but what I'm missing is what you are
actually trying to get at?


Here's what I'm trying to get at:  I think that the constant multiplier 
should be settable with xset, instead of requiring one to modify the 
Resolution option in XF86Config.

The issue was brought up last spring, and appearantly nothing was done
about it.


Since there's some confusion about that, let me explain how this thread 
relates to last spring's thread.

The issue disappeared from the mailing list, but I had some discussion 
offline with Joe Krahn about it after the mailing list posts that you 
saw.  During that discussion, I communicated with the woman who 
researched mouse acceleration algorithms at Apple, and she told me what 
algorithm Apple used and what her methodology was to come up with the 
algorithm.  In the end, my plan was to follow her methodology, and write 
a test application with which to experiment with different acceleration 
algorithms.  But I aborted this plan pretty quickly because I figured 
out how to make the existing algorithm work acceptably:

The trick is just to use the polynomial algorithm (by doing "xset m n/d 
0" or the like, where n and d are numbers, ie. "xset m 18/10 0" works 
well), and then to modify the Resolution option in XF86Config to taste.

I use a basic logitech wheel mouse (I think it's called the "first 
mouse"), and I've found these settings to work really well for me:

  xset m 29/20 0   # in .xinitrc
  Option "Resolution"  "200"   # in InputDevice section of XF86Config-4

(But be sure that the "xset m 29/20 0" command is executed after X 
starts and your gnome/kde/whatever settings daemon clobbers the mouse 
rate.  My current solution is to call the script "fixmouse-repeat&" in 
.xinitrc before gnome-session, where fixmouse-repeat does: 
"fixmouse;sleep 1;fixmouse;sleep 1;fixmouse;sleep 1;..." and fixmouse 
does "xset 29/20 0" in order to be sure that my xset settings take 
effect after gnome's.)

This will make your mouse cursor move according to the function "A * 
raw_mouse_speed^B", where A = some_constant/Resolution and B = n/d = 29/20.

This setup works really well for me!  The only problem is that it was a 
bitch to figure out the right values for Resolution and n/d (the 
exponent), since you have to restart X and modify XF86Config every time 
I wanted to change the constant multiplier.

Now, we've all been worried about finding a good mouse acceleration 
algorithm that suits more than a particular hacker's personal taste. 
But I think that the polynomial function that you get with threshold==0 
really IS "good enough" for all users!  I challenge everyone interested 
to try the polynomial function (set `threshold' in "xset m N/D 
threshold" to 0) and see if you can't find some parameters that make it 
work well for you.  Really, I think that once you try it (and get a good 
value for the Resolution and exponent) you'll agree that we don't need 
any more complicated algorithm.

Thus, right now I think the best solution would be to just keep the 
polynomial algorithm already implemented in XFree86, and simply 
implement some way of changing the constant multiplier with xset.  The 
problem is that it's hard to just go and add an extra run-time parameter 
to xset, since it involves modifying the X network protocol... here's an 
excerpt from a correspondence I had with Joe Krahn about this:

Anyway, is it ok to extend the xset syntax?


The problem is that this means changing the X network protocol.
Remember xset is a client. However, a mechanism for general
and more complex device control commands will be implemented
before long. For now, such advanced things would have to go
into XF86Config, and be stuck at runtime. Actually, we could use
integer Feedbacks to do it, buit that would be a temporary hack
until better device controls exist.


Xset lets us modify 3 numbers at runtime, but if we're using the 
polynomial function we only have 2 numbers (since the third has to be 
set to 0).  If we want to be able to modify the constant multiplier at 
runtime, we have to somehow do it with the numbers xset already gives 
us.  One option is the proposal I gave to start this thread (add a 
boolean option to XF86Config that changes the meaning of xset).  Another 
option is to remove support for the 2-level "threshold" acceleration 
algorithm entirely, and require people to use the polynomial "power" 
function (which is what Soeren's patch does).  A third option would be 
to split the exponent of the power function (the numerator and 
denominator) into two distinct values -- one for the exponent and one 
for the constant multiplier.

Of these options, I like the first two the best.  The third option 

[Xpert]Re: Proposal for mouse speed & acceleration settings

[Michael Toomim]

Craig Carey wrote:

Here are some arguments having considerations of deceleration appear in
this thread:


Ok, let me rephrase.  I'm not saying that what you're saying is 
irrelevant -- I agree that it needs to be discussed.  I was just 
pointing out that we are talking about two separate things:

 - I was taking issue with the mouse speed *settings*.  I thought that
   the constant multiplier parameter, which you can currently set via
   the "Resolution" parameter in XF86Config, would be much better off
   as an "xset" parameter that you can change dynamically at run-time.

 - You appear to be taking issue with the averaging code, and problems
   that arise within the current acceleration algorithms when the mouse
   moves at low speeds.

Am I misunderstanding your point?  Were you also talking about the 
interface to the acceleration algorithm's settings?

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: Patches in limbo - was Re: [Xpert]Re: Proposal for mouse speed & acceleration settings

[David Dawes]

On Sat, Nov 02, 2002 at 10:31:10AM +, Stephen Davies wrote:

>So those who send patches should expect some feedback or questions as to
>our code.
>
>I submitted a tdfx driver patch on 7th Oct:
>
>> Your submission to <[EMAIL PROTECTED]> has been assigned the
>> sequence number A.1297.
>
>I would have expected some sort of reply, perhaps one of:
>
> - patch accepted
> - send your patch to xx@yy, maintainer of the tdfx driver
> - we don't understand and won't apply - explain why you do ...
>
>In my case the tdfx driver isn't used so much anymore, less so the XVideo
>support that the patch improves.  Nevertheless, it seems selfish to keep
>the change to myself.

All patch submissions to XFree86 are welcome, but the only guarantee
you get when making a submission is that someone will look at it and
either review it or find someone else to review it.

There is no guarantee about when that will happen, but our goal is that
all submissions received in time for the next release will be reviewed
before that release is finalised.  It's unreasonable to expect the
volunteers who review submissions to do so on your timetable.  Until
it's reviewed, all we can tell you is that we received it and that it's
in our queue (that's what the automated reply does).

Once a submission is reviewed, any of the following may happen:

  1. submission found to be a duplicate, or problem already fixed
  2. committed with or without changes
  3. submitter contacted for further information
  4. held for further review
  5. rejected

For case 1, you probably won't hear anything back.  There's an assumption
that you're following the relevant area of the XFree86 development code,
so you'll already know if the problem you submitted a fix for has since
been fixed.

For case 2, you'll see that the submission has been committed via the
cvs-commit list (http://www.xfree86.org/mailman/listinfo/cvs-commit),
which is archived.  You can also look at the changelog extract on our
web site (http://www.xfree86.org/cvs/changes.html), which is updated
automatically at frequent intervals.  Both your name and the number
assigned to your submission should appear in the commit message and
changelog entry.

In cases 3 and 5 you should be contacted via email.  In case 4 it depends
on the further review.

David
--
David Dawes
Release Engineer/Architect  The XFree86 Project
www.XFree86.org/~dawes
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Re: Proposal for mouse speed & acceleration settings

[David Dawes]

On Fri, Nov 01, 2002 at 11:58:31PM -0800, J. Imlay wrote:
>I am just a casual reader on this list so I could be entirly wrong about
>all this.
>
>I've read the thread that you started last spring, and I've been following
>this one, and I sympathize with you on the problems with the acceleration
>in X (it's down right unusable IMHO) but what I'm missing is what you are
>actually trying to get at?
>
>The issue was brought up last spring, and appearantly nothing was done
>about it. And the problem doesn't seem to be lack of a patch it's just
>that someone (a mystery to me as well) doesn't seem to like to apply
>patches from anyone but ... well I don't know. Only a few of the inside
>guys get to change the code at all.

I think the problem in this particular case is lack of agreement about
the nature of the pointer accleration problem and/or its solution.  If
those interested in solving the problem can discuss it here and come to
some agreement on what the true nature of the problem is, and come up
with a fix that solves it, then the code will get changed.  Churning
the code by committing each personal preference solution that gets
submitted doesn't solve the problem (and that's how I'd characterise
most of the submissions that actually contained patches that I've seen
on this topic so far).

David
--
David Dawes
Release Engineer/Architect  The XFree86 Project
www.XFree86.org/~dawes
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Re: Proposal for mouse speed & acceleration settings

[Craig Carey]

At 2002\11\01 23:01 -0800 Friday, Michael Toomim wrote:
>At 2002\11\02 17:22 +1300 Saturday, Craig Carey wrote:

Correction: dx' = k1 *  * (+1 if dx > 0 else -1)
>>  dx' = k2 * dx
>>
>>  [dx is a C int, dx' is real that is added to a real sum and then
>>  later converted into a screen pixel position]
>
>I think we're miscommunicating here.  My issue has nothing to do with
>problems with small integers.  I just want to be able to control the
>mouse speed (not acceleration) with xset.
>
>Since these two issues are orthogonal, let's try to keep them in
>separate threads.
>

That can be rejected. Here are my arguments for doing that. It would not
be a great problem to have a new thread.

Here are some arguments having considerations of deceleration appear in
this thread:

(1) The 31 October 200 message of Mr Toomim, which started the thread, was
 all over the topic of the deceleration function and it even mentioned that
 the a power function was used, thus the small procedure implementing the
 deceleration probably was located.

(2) The title contains the words "mouse ... acceleration", so the subject
 field contained the topic. Not many messages here do contain the topic and
 I was only replying to other pre-existing threads on the topic of the
 deceleration algorithm;

(3) That first message of the thread had a significant purpose of having
 XFree86 altered so that the constant that is multiplied in, and that
 provides the accelerating, could be increased in real time. That is
 verifiable:

(4) A singe mathematical expression contains the multiplier and the
 'threshold' value that (mis)splices two curves together
--
At 2002\10\31 18:20 -0800 Thursday, Michael Toomim wrote:
>I propose adding an option to the XF86Config mouse settings that lets a
>user modify the mouse speed dynamically with xset, rather than with the
...
>addition, there's no way to speed up the mouse by a constant multiplier
>(independent of acceleration) without changing the "Resolution" option
>in XF86Config.  This requires a server restart, root access, isn't
--

Anyone can modify XFree86 and then increase the amplifying number.

But then this problem appears: a very small motion of the hardware mouse
will cause an approx. 20 pixel jump of the mouse cursor. That is due to
a lack of averaging code that is major cause of the overshooting mouse
with its dead diamond shaped region in the velocity plane.

Both the fast mouse and the slow mouse, are affected.


At 02\11\01 23:58 -0800 Friday, J. Imlay wrote:
...
>I've read the thread that you started last spring, and I've been following
>this one, and I sympathize with you on the problems with the acceleration
>in X (it's down right unusable IMHO)

Quite so: GNOME and KDE are unusable. However GNOME shut down bug reports
saying that it is an XFree86 problem. I think KDE was not processing their
bug report.

...
>But lambasting people for commenting there opinions on this matter as
>being off topic (even if they are) doesn't get any of us anywhere.

The author did not have backing of his message or the details of the topic
and this looks like an instance where users expect such patches to never
make it into the code.

That code seems to be in a C coding style: memcopy's, and no type checking,
and bugs [e.g. the discontinuity at the edge of the diamond shape, and
missing averaging code, and unnecessary loss of accuracy in the arithmetic
(use of "(int)")].

To provide averaging code won't alter the behaviour of the sliders in
GNOME and KDE so in addition to having very easy to write code that would
produce a noticeable improvement, it ought be able to avoid being
controversial. Obviously a fix is needed (I am not intending to produce
a patch for months).



The mouse deceleration algorithm: xf86PostMotionEvent():
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/common/xf86Xinput.c



Craig Carey
Auckland, New Zealand





Craig Carey

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: Patches in limbo - was Re: [Xpert]Re: Proposal for mouse speed & acceleration settings

[Alan Hourihane]

On Sat, Nov 02, 2002 at 10:31:10AM +, Stephen Davies wrote:
> On Sat, 2 Nov 2002, Dr Andrew C Aitchison wrote:
> 
> > Speaking as someone in the "outer circle" (I'm on the private lists, but 
> > don't get to change the code) I think that the problem is that none one will 
> > commit a patch that they don't understand.
> 
> Hi Andrew,
> 
> So those who send patches should expect some feedback or questions as to
> our code.
> 
> I submitted a tdfx driver patch on 7th Oct:
> 
> > Your submission to <[EMAIL PROTECTED]> has been assigned the
> > sequence number A.1297.
> 
> I would have expected some sort of reply, perhaps one of:
> 
>  - patch accepted
>  - send your patch to xx@yy, maintainer of the tdfx driver
>  - we don't understand and won't apply - explain why you do ...
> 

The best way to check if your patch has been integrated is to
check the CHANGELOG file in xc/programs/Xserver/hw/xfree86.

If it's already been applied, then it will show up there. We just
don't have the time to followup with every single person that
submits patches.

If it's not already been applied, then just be patient. If after
a few months, you may feel the need to check. That's fine. You
may get a response to say that we've still not looked at the patch.

But please do, check CHANGELOG for more details.

Alan.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: Patches in limbo - was Re: [Xpert]Re: Proposal for mouse speed& acceleration settings

[Dr Andrew C Aitchison]

On Sat, 2 Nov 2002, Stephen Davies wrote:

> On Sat, 2 Nov 2002, Dr Andrew C Aitchison wrote:
> 
> > Speaking as someone in the "outer circle" (I'm on the private lists, but 
> > don't get to change the code) I think that the problem is that none one will 
> > commit a patch that they don't understand.
> 
> Hi Andrew,
> 
> So those who send patches should expect some feedback or questions as to
> our code.
> 
> I submitted a tdfx driver patch on 7th Oct:
> 
> > Your submission to <[EMAIL PROTECTED]> has been assigned the
> > sequence number A.1297.
> 
> I would have expected some sort of reply, perhaps one of:
> 
>  - patch accepted
>  - send your patch to xx@yy, maintainer of the tdfx driver
>  - we don't understand and won't apply - explain why you do ...

That would be reasonable, but *somebody* would have make such a decision.
If your patch falls within the interest of on the developers with commit 
access it will be accepted (or rejected) quickly.
However, my impression is that the [EMAIL PROTECTED] address is so 
short-staffed that other patches may be stuck in a queue for a substantial
time (I think I've had patches take two months before I've heard 
anything).
If we don't have a tdfx maintainer your second suggestion isn't an option;
and a message "your patch looks interesting, but we can't handle 
developments in that area of the server" sounds bad.
Conscientious, overloaded people have a habit of trying to do the right 
thing later, rather than the wrong thing now.
 
I don't really know how we can get more resource into handling submitted 
patches; we can't get just anyone to do it since this is a major part of 
our quality control, and even our most experienced, active developers
are capable of submitting canges which cause problems.

Should we try to raise money to hire someone with a lot of experience
of the X code, not to do development, but to process the patch queue ?

-- 
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED]   http://www.dpmms.cam.ac.uk/~werdna

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: Patches in limbo - was Re: [Xpert]Re: Proposal for mouse speed & acceleration settings

[Olivier Chapuis]

On Sat, Nov 02, 2002 at 09:09:25AM +, Dr Andrew C Aitchison wrote:
> On Fri, 1 Nov 2002, J. Imlay wrote:
> 
> > I am just a casual reader on this list so I could be entirly wrong about
> > all this.
> > 
> > I've read the thread that you started last spring, and I've been following
> > this one, and I sympathize with you on the problems with the acceleration
> > in X (it's down right unusable IMHO) but what I'm missing is what you are
> > actually trying to get at?
> > 
> > The issue was brought up last spring, and appearantly nothing was done
> > about it. And the problem doesn't seem to be lack of a patch it's just
> > that someone (a mystery to me as well) doesn't seem to like to apply
> > patches from anyone but ... well I don't know. Only a few of the inside
> > guys get to change the code at all.
> 
> Speaking as someone in the "outer circle" (I'm on the private lists, but 
> don't get to change the code) I think that the problem is that none one will 
> commit a patch that they don't understand.
> 
> We can't just make changes, however great, without considering what
> happens to people and programs which expect things to be the (broken)
> way they have always been.
> As a result, anyone who makes changes is expected to deal with any
> problems that show up because of their changes (there are two
> "interesting" threads on the main private list at the moment
> which could be said to be putting pressure on one of the big names
> becuase he is slow to deal with the consequences of some great new 
> features).
>

I do not understand why there are private lists. It is frustrating to
learn that there are interesting discussions on such lists that people
which want to "help" the xpert's cannot read. IMHO such lists should be
at least read-only lists (or better moderated, but this leads to
additional works)
 
Regards, Olivier 
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: Patches in limbo - was Re: [Xpert]Re: Proposal for mouse speed& acceleration settings

[Stephen Davies]

On Sat, 2 Nov 2002, Dr Andrew C Aitchison wrote:

> Speaking as someone in the "outer circle" (I'm on the private lists, but 
> don't get to change the code) I think that the problem is that none one will 
> commit a patch that they don't understand.

Hi Andrew,

So those who send patches should expect some feedback or questions as to
our code.

I submitted a tdfx driver patch on 7th Oct:

> Your submission to <[EMAIL PROTECTED]> has been assigned the
> sequence number A.1297.

I would have expected some sort of reply, perhaps one of:

 - patch accepted
 - send your patch to xx@yy, maintainer of the tdfx driver
 - we don't understand and won't apply - explain why you do ...

In my case the tdfx driver isn't used so much anymore, less so the XVideo
support that the patch improves.  Nevertheless, it seems selfish to keep
the change to myself.

OTOH - my offer of the code is in the Xpert archive so it can be
found.  One person asked for it so far - so perhaps that is sufficient.

Regards,
Steve

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Patches in limbo - was Re: [Xpert]Re: Proposal for mouse speed &acceleration settings

[Dr Andrew C Aitchison]

On Fri, 1 Nov 2002, J. Imlay wrote:

> I am just a casual reader on this list so I could be entirly wrong about
> all this.
> 
> I've read the thread that you started last spring, and I've been following
> this one, and I sympathize with you on the problems with the acceleration
> in X (it's down right unusable IMHO) but what I'm missing is what you are
> actually trying to get at?
> 
> The issue was brought up last spring, and appearantly nothing was done
> about it. And the problem doesn't seem to be lack of a patch it's just
> that someone (a mystery to me as well) doesn't seem to like to apply
> patches from anyone but ... well I don't know. Only a few of the inside
> guys get to change the code at all.

Speaking as someone in the "outer circle" (I'm on the private lists, but 
don't get to change the code) I think that the problem is that none one will 
commit a patch that they don't understand.

We can't just make changes, however great, without considering what
happens to people and programs which expect things to be the (broken)
way they have always been.
As a result, anyone who makes changes is expected to deal with any
problems that show up because of their changes (there are two
"interesting" threads on the main private list at the moment
which could be said to be putting pressure on one of the big names
becuase he is slow to deal with the consequences of some great new 
features).

We don't have experts in every area, so some patches have to wait until 
somone has the time or inclination (we are mostly volunteers, remember)
to understand them well enough to take responsibility for the 
consequences of the patch.
While several people do commit changes submitted to the lists, there is 
only one person paid to integrate patches and generally "look after the 
code", anyone else who has a job is "adding features" or supporting 
hardware, or "developing the server", ie *writing* code. Few of these 
poeple seem to have the time to take on new areas of the code, and are 
more interested in improving the bit they know well.


-- 
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED]   http://www.dpmms.cam.ac.uk/~werdna



___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Re: Proposal for mouse speed & acceleration settings

[J. Imlay]

I am just a casual reader on this list so I could be entirly wrong about
all this.

I've read the thread that you started last spring, and I've been following
this one, and I sympathize with you on the problems with the acceleration
in X (it's down right unusable IMHO) but what I'm missing is what you are
actually trying to get at?

The issue was brought up last spring, and appearantly nothing was done
about it. And the problem doesn't seem to be lack of a patch it's just
that someone (a mystery to me as well) doesn't seem to like to apply
patches from anyone but ... well I don't know. Only a few of the inside
guys get to change the code at all.

But lambasting people for commenting there opinions on this matter as
being off topic (even if they are) doesn't get any of us anywhere.

So more to the point, what are you actually trying to convince who to do?
The real issue isn't that you propose a change. It's that your pissed
that they wont commit any of the fixes to the problem.

Sorry about the rant. I feel like I'm preching and I've no right to do so.
But I would really like to see this fixed and it just looks like your ...
"not playing the game right"?

I don't know.. I'm just a nerd and no one ever listens to me anyways, so
if I sound like an asshole. Just ignore me I don't mean to be.

Good luck.

Josie Imlay




___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: Proposal for mouse speed & acceleration settings

[Michael Toomim]

Craig Carey wrote:


The XFree86 mouse deceleration function gets dx,dy integers that are
small integers in between -1 and +1 quite often. Whatever the function
("formula") was, it could be replaced with these two without much change:

  dx' = k1 * dx * (+1 if dx > 0 else -1)
  dx' = k2 * dx

 [dx is a C int, dx' is real that is added to a real sum and then
 later converted into a screen pixel position]


I think we're miscommunicating here.  My issue has nothing to do with 
problems with small integers.  I just want to be able to control the 
mouse speed (not acceleration) with xset.

Since these two issues are orthogonal, let's try to keep them in 
separate threads.

Michael

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert