linuxconsole-dev

Re: [patch] Fix suspend of the kseriod thread

[Vojtech P. <vo...@su...>]

On Wed, Jul 31, 2002 at 11:07:21AM +0100, David Woodhouse wrote:

> vo...@su... said:
> >  Ok. Is the use in drivers/input/serio.c buggy? 
> 
> If it matters that the thread can miss wakeup events and sleep indefinitely 
> while there's a 'SERIO_RESCAN' event pending, then yes it looks buggy.
> 
> 	serio_thread()				serio_rescan()
> 	--------------				--------------
> 
> 	serio_handle_events();
> 						serio->event |= SERIO_RESCAN;
> 						wake_up(&serio_wait);
> 	sleep_on(&serio_wait);
> 
> 	...sleeps...
> 
> If both serio_thread() and serio_rescan() hold the BKL you're OK. It looks 
> like serio_rescan() doesn't, though.

Thanks for the explanation. Yes, this could happen.

> > What should be it replaced with?
> 
> In general, the response 'anything but sleep_on' is considered appropriate.
> Try wait_event().

-- 
Vojtech Pavlik
SuSE Labs

Re: [patch] Fix suspend of the kseriod thread

[Vojtech P. <vo...@su...>]

On Wed, Jul 31, 2002 at 10:55:54AM +0100, David Woodhouse wrote:

> rm...@ar... said:
> >  Isn't interruptible_sleep_on() taboo? 
> 
> With the demise of cli() and the continued removal of the BKL, all users of 
> sleep_on() are probably buggy. We should remove it completely.

Ok. Is the use in drivers/input/serio.c buggy?
What should be it replaced with?

-- 
Vojtech Pavlik
SuSE Labs

Re: [patch] Fix suspend of the kseriod thread

[David W. <dw...@in...>]

rm...@ar... said:
>  Isn't interruptible_sleep_on() taboo? 

With the demise of cli() and the continued removal of the BKL, all users of 
sleep_on() are probably buggy. We should remove it completely.

--
dwmw2

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Alexander V. <vi...@ma...>]

On Tue, 30 Jul 2002, Alexander Viro wrote:

> > > ICBW, but wasn't uint<n>_t only promised to be at least <n> bits?

As the matter of fact, IHBW.

> > I am not sure I understand the point you are trying to make.

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Linus T. <tor...@tr...>]

On Wed, 31 Jul 2002, Brad Hards wrote:
>
> Here is an extract from <linux/types.h>
> typedef         __u8            uint8_t;
> typedef         __u16           uint16_t;

Yes, and the thing you snipped from it was that it's inside a #ifdef.

Now, that #ifdef will be on for the __KERNEL__, but somebody else might
have compiled with some -traditional switch or other that disabled
"uint8_t" or just screwed it up some other way.

> > ICBW, but wasn't uint<n>_t only promised to be at least <n> bits?
> I am not sure I understand the point you are trying to make.

I think the point Viro is making is that uint8_t actually exists on things 
like old cray's too, even if end sup being a 64-bit entity.

I don't think that is correct, though. I think that comes from another
(proposed but not implemented) C language extension that would have
allowed something like that, namely the

	int X:17;

syntax, where X would be guaranteed to be "17 bits or more". I don't 
remember.

		Linus

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Vojtech P. <vo...@su...>]

On Tue, Jul 30, 2002 at 02:46:12PM -0700, Linus Torvalds wrote:

>  - in this case, maybe just adding a new cset is the proper thing. 
>    Especially as reversing the cset doesn't actually get you where you
>    want anyway, since you'd still have to do the "unsigned short" -> "u16"  
>    translation as yet another cset.

Ok, here you go:

===================================================================

ChangeSet@1.533, 2002-07-30 23:54:08+02:00, vo...@su...
  Revert input.h back to kernel types.

 input.h |   84 ++++++++++++++++++++++++++++++++--------------------------------
 1 files changed, 42 insertions(+), 42 deletions(-)

diff -Nru a/include/linux/input.h b/include/linux/input.h
--- a/include/linux/input.h	Wed Jul 31 00:01:00 2002
+++ b/include/linux/input.h	Wed Jul 31 00:01:00 2002
@@ -32,7 +32,7 @@
 #else
 #include <sys/time.h>
 #include <sys/ioctl.h>
-#include <stdint.h>
+#include <asm/types.h>
 #endif
 
 /*
@@ -41,9 +41,9 @@
 
 struct input_event {
 	struct timeval time;
-	uint16_t type;
-	uint16_t code;
-	int32_t value;
+	__u16 type;
+	__u16 code;
+	__s32 value;
 };
 
 /*
@@ -57,18 +57,18 @@
  */
 
 struct input_id {
-	uint16_t bustype;
-	uint16_t vendor;
-	uint16_t product;
-	uint16_t version;
+	__u16 bustype;
+	__u16 vendor;
+	__u16 product;
+	__u16 version;
 };
 
 struct input_absinfo {
-	int value;
-	int minimum;
-	int maximum;
-	int fuzz;
-	int flat;
+	__s32 value;
+	__s32 minimum;
+	__s32 maximum;
+	__s32 fuzz;
+	__s32 flat;
 };
 
 #define EVIOCGVERSION		_IOR('E', 0x01, int)			/* get driver version */
@@ -611,62 +611,62 @@
  */
 
 struct ff_replay {
-	uint16_t length; /* Duration of an effect in ms. All other times are also expressed in ms */
-	uint16_t delay;  /* Time to wait before to start playing an effect */
+	__u16 length; /* Duration of an effect in ms. All other times are also expressed in ms */
+	__u16 delay;  /* Time to wait before to start playing an effect */
 };
 
 struct ff_trigger {
-	uint16_t button;   /* Number of button triggering an effect */
-	uint16_t interval; /* Time to wait before an effect can be re-triggered (ms) */
+	__u16 button;   /* Number of button triggering an effect */
+	__u16 interval; /* Time to wait before an effect can be re-triggered (ms) */
 };
 
 struct ff_envelope {
-	uint16_t attack_length;	/* Duration of attack (ms) */
-	uint16_t attack_level;	/* Level at beginning of attack */
-	uint16_t fade_length;	/* Duration of fade (ms) */
-	uint16_t fade_level;	/* Level at end of fade */
+	__u16 attack_length;	/* Duration of attack (ms) */
+	__u16 attack_level;	/* Level at beginning of attack */
+	__u16 fade_length;	/* Duration of fade (ms) */
+	__u16 fade_level;	/* Level at end of fade */
 };
 
 /* FF_CONSTANT */
 struct ff_constant_effect {
-	int16_t level;	    /* Strength of effect. Negative values are OK */
+	__s16 level;	    /* Strength of effect. Negative values are OK */
 	struct ff_envelope envelope;
 };
 
 /* FF_RAMP */
 struct ff_ramp_effect {
-	int16_t start_level;
-	int16_t end_level;
+	__s16 start_level;
+	__s16 end_level;
 	struct ff_envelope envelope;
 };
 
 /* FF_SPRING of FF_FRICTION */
 struct ff_condition_effect {
-	uint16_t right_saturation; /* Max level when joystick is on the right */
-	uint16_t left_saturation;  /* Max level when joystick in on the left */
+	__u16 right_saturation; /* Max level when joystick is on the right */
+	__u16 left_saturation;  /* Max level when joystick in on the left */
 
-	int16_t right_coeff;	/* Indicates how fast the force grows when the
+	__s16 right_coeff;	/* Indicates how fast the force grows when the
 				   joystick moves to the right */
-	int16_t left_coeff;	/* Same for left side */
+	__s16 left_coeff;	/* Same for left side */
 
-	uint16_t deadband;	/* Size of area where no force is produced */
-	int16_t center;	/* Position of dead zone */
+	__u16 deadband;	/* Size of area where no force is produced */
+	__s16 center;	/* Position of dead zone */
 
 };
 
 /* FF_PERIODIC */
 struct ff_periodic_effect {
-	uint16_t waveform;	/* Kind of wave (sine, square...) */
-	uint16_t period;	/* in ms */
-	int16_t magnitude;	/* Peak value */
-	int16_t offset;	/* Mean value of wave (roughly) */
-	uint16_t phase;		/* 'Horizontal' shift */
+	__u16 waveform;	/* Kind of wave (sine, square...) */
+	__u16 period;	/* in ms */
+	__s16 magnitude;	/* Peak value */
+	__s16 offset;	/* Mean value of wave (roughly) */
+	__u16 phase;		/* 'Horizontal' shift */
 
 	struct ff_envelope envelope;
 
 /* Only used if waveform == FF_CUSTOM */
-	uint32_t custom_len;	/* Number of samples  */	
-	int16_t *custom_data;	/* Buffer of samples */
+	__u32 custom_len;	/* Number of samples  */	
+	__s16 *custom_data;	/* Buffer of samples */
 /* Note: the data pointed by custom_data is copied by the driver. You can
  * therefore dispose of the memory after the upload/update */
 };
@@ -677,22 +677,22 @@
    by the heavy motor.
 */
 struct ff_rumble_effect {
-	uint16_t strong_magnitude;  /* Magnitude of the heavy motor */
-	uint16_t weak_magnitude;    /* Magnitude of the light one */
+	__u16 strong_magnitude;  /* Magnitude of the heavy motor */
+	__u16 weak_magnitude;    /* Magnitude of the light one */
 };
 
 /*
  * Structure sent through ioctl from the application to the driver
  */
 struct ff_effect {
-	uint16_t type;
+	__u16 type;
 /* Following field denotes the unique id assigned to an effect.
  * If user sets if to -1, a new effect is created, and its id is returned in the same field
  * Else, the user sets it to the effect id it wants to update.
  */
-	int16_t id;
+	__s16 id;
 
-	uint16_t direction;	/* Direction. 0 deg -> 0x0000 (down)
+	__u16 direction;	/* Direction. 0 deg -> 0x0000 (down)
 					     90 deg -> 0x4000 (left)
 					    180 deg -> 0x8000 (up)
 					    270 deg -> 0xC000 (right)

===================================================================

This BitKeeper patch contains the following changesets:
1.533
## Wrapped with gzip_uu ##


begin 664 bkpatch24435
M'XL(`)P,1ST``[56V7+;.!!\%K]BJO*0:TV!IPZO4SFTF[ARN>S-LPLB(1$Q
M"2@$*-DN??P.`%*4;">I[&&[2.&8GIZ>!N1'\$6Q>CI8RZ^:987W"-Y)I:<#
MU2CF9[<X/I<2Q\-"5FS8[AK.KX9<K!KMX?H9U5D!:U:KZ2#PH]V,OEFQZ>#\
MC[=?/KPZ][R3$WA34+%D%TS#R8FG9;VF9:Y>4EV44OBZID)53%,_D]5VMW4;
M$A+B;Q*,(I*DVR`E\6B;!7D0T#A@.0GC<1I[?V+TK7_!Z_)E21O-ZCG-BH>0
M$`7?XR#91NF$1-X,`C^)(B#AD(R&$8$PFB;QE(R?DW!*"+05OVSU@.<!'!'O
M-?RW]-]X&9PSU%"#U=4O``NXPBQPQ6K!2JNF\KWW8&BGWEDOIG?TBS^>1RCQ
M7ORD!"ZRLLG9L.2BN1ZVK/;+F<3!-HWC8+Q=1.%\'$9INF"$43*^*]J/L$P_
M@B0FR3:()NG8^N3![3_WS+]@[/T:XR`*)A'9AO$HG%@'!<D]`R7?,U`<PE$<
M_B\6>BMWMKF\;(+TGGF<QI_AJ-[8/S3#V<-R_P-7S:($`N_4/A^UH/`[5=70
MY2]>>+,XAL@[C5-\#AQ%LW;<#3*9NX&*0D!Q&AS-4@*Q=YI&^&RWS1MU$+9F
M(I?U;KBJ9=YD>F^Y5EP*`S6"Q#L=!?@\3-*.*BYXU53]F%X?C!?-[6T_**DV
MF$$,(?)##X1=QI*)I2Z.8?@,9DU--68'N0`J@"T6+#.G'"KEPZNR!*D+5H/F
M%5-`:P:T5!+8]:IF2K'<[81GPPXZ9R6].08#_1?&F%YO*-<P9PM9VZ'2%.^1
M%6[C8KF7$S&0[,22#4E/=MYHC>J`Q?S45'.D@V3=-.B:+Y>LO@?5!G.!ERV*
M>/P]0GU0AA_G#&IVU&)B=4\J]=01"V/;Y7#4MYEJC6Z^;,4<W!73KNX0[L:L
M66E#/IA/.(VIEUP(4T<?W,<M:,Z^E\FLW<W3[K^7!9VX"[%UH5$"XU[S,L:Q
M[K!AX!2_T+5-:\*<4CY\8DO,OF;.GLX7G]^W@&/;P6CB.F@`;<=;-MT<$NEF
M9FF<V!@\=[NN8PL*?:FH;@NU#?Q(KQT[V!1,P%=YHS1'G;@"8X6"N;`]'4JV
M.$3Y(8SH8$R8*R<>6WWLJZ7NJ&42U;#BGHJ<9U2C#H7<H+1*6PRT5\9@6<N-
M<GEP$@$38@'M:R?X8A_O@E8VVK%0O&M5$EJ5DJA7*6<TGU.1NSA^RZQY:D9-
M1FR*D"T-5,A=.VAJIXY)G#%S/&SPF52\,Y1!A5LINKP3<RNE>,,E7=X-79OC
M4]G0]]R9RDS"$\4%^PW4MP9I^+Z_;\H5GE/IN.Y?&X9)19>":[R1'1E&KYRW
M]K;(Q4(Q;=<_,CRK;GV7MY;-LBAO#O(55"&@B7C\3M8<2]*T?`RJX%U[4^?6
MM'5K@^<@P]M;5N:PV5S]C:-HM2JQRQ@YZ$@]:W?G5%.[_76#9^1@N\TS)C;/
M..A[IW0MQ?*RK[SU9CLT$,9&!:/K&Z@D?AWOE;9!A0Y"'PXN[7'8=7+LS#QN
MS=Q_O\W22627[*NMC>=V(7$+21^3\QJO`7.<[%74C7P@:)TE'+T`<DWP!Y[D
=<B.>]O^%9P7+KE13G:0Q96F>Q=[?IV!"D>`+````
`
end

-- 
Vojtech Pavlik
SuSE Labs

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Alexander V. <vi...@ma...>]

On Wed, 31 Jul 2002, Brad Hards wrote:

> On Wed, 31 Jul 2002 07:42, Alexander Viro wrote:
> <snip>
> > Strictly speaking, there might be a DISadvantage - IIRC, there's nothing to
> > stop gcc from
> > #define uint8_t unsigned long long	/* it is at least 8 bits */
> Here is an extract from <linux/types.h>
> typedef         __u8            uint8_t;
> typedef         __u16           uint16_t;
> 
> > ICBW, but wasn't uint<n>_t only promised to be at least <n> bits?
> I am not sure I understand the point you are trying to make.

The difference between compiler's "unsigned at least n bits" and kernel's
"unsigned exactly n bits".  They may very well be the same on all platforms
we are interested in presuming that compiler is sane, but at the very least
the implied meaning is different.

Re: [patch] Fix suspend of the kseriod thread

[Vojtech P. <vo...@su...>]

On Tue, Jul 30, 2002 at 10:57:36PM +0100, Russell King wrote:
> On Tue, Jul 30, 2002 at 10:17:22PM +0200, Vojtech Pavlik wrote:
> >  	do {
> >  		serio_handle_events();
> > +		interruptible_sleep_on(&serio_wait); 
> >  		if (current->flags & PF_FREEZE)
> >  			refrigerator(PF_IOTHREAD);
> > -		interruptible_sleep_on(&serio_wait); 
> >  	} while (!signal_pending(current));
> 
> Isn't interruptible_sleep_on() taboo?

As far as I know it only implies a bug when used with some condition,
like "buffer non-empty" etc. As always, I may be wrong, of course.

-- 
Vojtech Pavlik
SuSE Labs

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Linus T. <tor...@tr...>]

On Tue, 30 Jul 2002, Jeff Garzik wrote:
> 
> Agreed, but u16 is even better :)  Why use the '__' prefix when standard 
> kernel types do not need them?

The __ thing is actually fairly useful, for a few reasons

 - "u16" is namespace pollution and mustn't be exported by standard 
   user-level header files, since a program might use it as a variable 
   name.

 - it shows which things are purely krnel internal (u16 is 
   kernel-internal, but a structure with __u16 is in a structure exported
   to user space. Of course, some people seem to think that you should 
   always use the __u16 form, which is wrong. The underscores have
   meaning, and the meaning is exactly that: exported to user space
   headers as a size)

 - typedef's are nasty, in that you cannot mix them. With a #define, you 
   can just have

	#ifndef NULL
	#define NULL ((void *)0)
	#endif

   and if everybody follows that convention, duplicating a few #defines 
   isn't a problem.

   The same is _not_ true of typedefs. With typedefs, there can be only 
   one, and trying to avoid duplication with magic preprocessor rules 
   easily gets nasty. Sure, you can make up a rule like

	#ifndef __typedef_xxxx_t
	typedef ... xxxx_t;
	#endif

   but it's nowhere near as convenient as for #defines, and there is no 
   standard for this.

   This nastiness is why everybody (including things like glibc) ends up 
   having to have an internal type and an external type anyway. Have you
   ever wondered by the glibc header files internally use things like
   __off_t, __locale_t etc? This is why. To avoid duplicate defines, 
   especially in the presense of complex #ifdef __BSD_SOURCE__ etc, the 
   internal type is defined unconditionally. The externally visible type 
   is only defined if it should be.

See the crap in <linux/types.h> on how the linux headers define things
like u_int8_t int8_t uint8_t depending on different #defines. Which is why 
it is so convenient to have _one_true_ internal type (__u8) which you can 
always depend on, regardless of who compiles you and with what options. 

All the other types (inluding the "standard" uint8_t) simply cannot be 
depended on. 

		Linus

Re: [patch] Fix suspend of the kseriod thread

[Russell K. <rm...@ar...>]

On Tue, Jul 30, 2002 at 10:17:22PM +0200, Vojtech Pavlik wrote:
>  	do {
>  		serio_handle_events();
> +		interruptible_sleep_on(&serio_wait); 
>  		if (current->flags & PF_FREEZE)
>  			refrigerator(PF_IOTHREAD);
> -		interruptible_sleep_on(&serio_wait); 
>  	} while (!signal_pending(current));

Isn't interruptible_sleep_on() taboo?

-- 
Russell King (rm...@ar...)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Brad H. <bh...@bi...>]

On Wed, 31 Jul 2002 07:42, Alexander Viro wrote:
<snip>
> Strictly speaking, there might be a DISadvantage - IIRC, there's nothing to
> stop gcc from
> #define uint8_t unsigned long long	/* it is at least 8 bits */
Here is an extract from <linux/types.h>
typedef         __u8            uint8_t;
typedef         __u16           uint16_t;

> ICBW, but wasn't uint<n>_t only promised to be at least <n> bits?
I am not sure I understand the point you are trying to make.

Brad
-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Linus T. <tor...@tr...>]

On Tue, 30 Jul 2002, Vojtech Pavlik wrote:
> 
> Now the question remaining is how to fix that? You can just skip the
> patch. I've tried a 'bk undo', but that complains about unmerged leaves
> in that case (though really nothing depends on those changes). Or should
> I just make another cset on top of all the previous?

Ugh. there's a few things you can do

 - I often actually do a "bk undo -axxx" and then just re-do the parts I 
   want to re-do.

   NOTE! This only works if you haven't already had people pull from your 
   repository (or you'll need to ask them to do the "bk undo" as well).

 - You can reverse the cset, which means that it's still there, but there 
   is also a cset that says "undo that other cset". I prefer to not pull 
   those kinds of undo's, but they do happen, and I occasionally do them
   myself. I try to avoid it, but it's very useful for debugging ("does 
   that problem go away if I undo just that one cset?"), and sometimes 
   it _is_ the sanest way to go.

   So do "bk cset -xA.BBB"

 - in this case, maybe just adding a new cset is the proper thing. 
   Especially as reversing the cset doesn't actually get you where you
   want anyway, since you'd still have to do the "unsigned short" -> "u16"  
   translation as yet another cset.

I only get upset if the tree looks _really_ cluttered, in which case I may 
ask you to re-do it (that's happened once with the reiserfs tree).

			Linus

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Jeff G. <jg...@ma...>]

Greg KH wrote:
> On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
>>-	__u16 bustype;
>>-	__u16 vendor;
>>-	__u16 product;
>>-	__u16 version;
>>+	uint16_t bustype;
>>+	uint16_t vendor;
>>+	uint16_t product;
>>+	uint16_t version;
> 
> 
> {sigh}  __u16 is _so_ much nicer, and tells the programmer, "Yes I know
> this variable needs to be the same size in userspace and in
> kernelspace."


Agreed, but u16 is even better :)  Why use the '__' prefix when standard 
kernel types do not need them?

	Jeff

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Alexander V. <vi...@ma...>]

On Tue, 30 Jul 2002, Linus Torvalds wrote:

> 
> On Wed, 31 Jul 2002, Brad Hards wrote:
> > 
> > We shouldn't arbitrarily invent new types that could be trivially done with 
> > standard types. Maybe we could retain existing usage for ABIs that are
> > unchanged from 2.0 days, but we certainly shouldn't be making the ABI
> > any worse.
> 
> I disagree. 
> 
> I actively _dislike_ those stupid standard typenames. I don't want them in 
> the kernel, and they have no advantages over the standard kernel types 
> that have been there for a _loong_ time.

Strictly speaking, there might be a DISadvantage - IIRC, there's nothing to
stop gcc from
#define uint8_t unsigned long long	/* it is at least 8 bits */
ICBW, but wasn't uint<n>_t only promised to be at least <n> bits?

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Brad H. <bh...@bi...>]

On Wed, 31 Jul 2002 07:20, Linus Torvalds wrote:
> On Tue, 30 Jul 2002, Greg KH wrote:
> > On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
> > > -#include <asm/types.h>
> > > +#include <stdint.h>
> >
> > Why?  I thought we were not including any glibc (or any other libc)
> > header files when building the kernel?
>
> Indeed. This is unacceptable.
Its a minor thinko - <linux/types.h> is the right definition.

> Especially as the standard types are total crap, and the u8 etc are a lot
> more readable. People should realize:
>
>  - the "int" is superfluous. Of _course_ it's an integer. If it was a
>    floating point number, it would be fp16/fp32/fp64/fp80/whatever.
>  - the "_t" is there only for namespace collisions, sane people can chose
>    to ignore it.
Sure, it is a convention that only a committee could love.
But it is at least widely understood by userspace programmers.

> What do you have left after you have removed the crap? Yup. u8, u16, etc.
Fine for internal to the kernel. Absolutely. Required knowledge to play
with the kernel.

> And if you want to share with user space, there's the long-accepted
> namespace collision avoidance of prepending two underscores.
This is where we disagree. __u8 requires the (userspace) programmer
to go off, find out that __u8 is really some wierd Linux-ism that he
can safely map to uint8_t, to use with the rest of the *standard* library
routines.

> Fix it, Vojtech.
Please don't be hasty.

This isn't about the kernel representation. It is about making ABIs as
easy as possible for userspace programmers to use. If there is an
ugly but standard way, and an almost-as-ugly and non-standard way,
I don't think that the standard way is too much to ask.

Brad
-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Vojtech P. <vo...@su...>]

On Wed, Jul 31, 2002 at 07:26:05AM +1000, Brad Hards wrote:
> On Wed, 31 Jul 2002 07:09, Greg KH wrote:
> > On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
> > > -#include <asm/types.h>
> > > +#include <stdint.h>
> >
> > Why?  I thought we were not including any glibc (or any other libc)
> > header files when building the kernel?
> Should be <linux/types.h>

It's #ifndef __KERNEL__ and if we #include <linux/types.h> and the user
#includes <stdint.h> elsewhere, we're going to get collisions.

I guess __u16 is really the safe way here.

> > > -	__u16 bustype;
> > > -	__u16 vendor;
> > > -	__u16 product;
> > > -	__u16 version;
> > > +	uint16_t bustype;
> > > +	uint16_t vendor;
> > > +	uint16_t product;
> > > +	uint16_t version;
> >
> > {sigh}  __u16 is _so_ much nicer, and tells the programmer, "Yes I know
> > this variable needs to be the same size in userspace and in
> > kernelspace."
> I'll harp some more.
> 1. __u16 isn't really any nicer - its just what you (as a kernel programmer) are used to.
> 2. uint16_t is a *standard* type. Userspace programmer know it, even if they don't know Linux. 
> 
> We shouldn't arbitrarily invent new types that could be trivially done with 
> standard types. Maybe we could retain existing usage for ABIs that are
> unchanged from 2.0 days, but we certainly shouldn't be making the ABI
> any worse.

-- 
Vojtech Pavlik
SuSE Labs

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Vojtech P. <vo...@su...>]

On Tue, Jul 30, 2002 at 02:20:36PM -0700, Linus Torvalds wrote:

> On Tue, 30 Jul 2002, Greg KH wrote:
>=20
> > On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
> > > -#include <asm/types.h>
> > > +#include <stdint.h>
> >=20
> > Why?  I thought we were not including any glibc (or any other libc)
> > header files when building the kernel?
>=20
> Indeed. This is unacceptable.
>=20
> Especially as the standard types are total crap, and the u8 etc are a l=
ot=20
> more readable. People should realize:
>=20
>  - the "int" is superfluous. Of _course_ it's an integer. If it was a=20
>    floating point number, it would be fp16/fp32/fp64/fp80/whatever.
>  - the "_t" is there only for namespace collisions, sane people can cho=
se=20
>    to ignore it.
>=20
> What do you have left after you have removed the crap? Yup. u8, u16, et=
c.=20
> And if you want to share with user space, there's=A0the long-accepted=20
> namespace collision avoidance of prepending two underscores.
>=20
> Fix it, Vojtech.
>=20
> 		Linus

I will, and will do so happily. I don't like the uint*_t types as well.
This change was pushed very heavily for by Brad Hards, based on a
conclusion of a rather lengthy discussion (I think on linux-usb) on
which types should be used.

Now the question remaining is how to fix that? You can just skip the
patch. I've tried a 'bk undo', but that complains about unmerged leaves
in that case (though really nothing depends on those changes). Or should
I just make another cset on top of all the previous?

--=20
Vojtech Pavlik
SuSE Labs

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Linus T. <tor...@tr...>]

On Wed, 31 Jul 2002, Brad Hards wrote:
> 
> We shouldn't arbitrarily invent new types that could be trivially done with 
> standard types. Maybe we could retain existing usage for ABIs that are
> unchanged from 2.0 days, but we certainly shouldn't be making the ABI
> any worse.

I disagree. 

I actively _dislike_ those stupid standard typenames. I don't want them in 
the kernel, and they have no advantages over the standard kernel types 
that have been there for a _loong_ time.

		Linus

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Brad H. <bh...@bi...>]

On Wed, 31 Jul 2002 07:09, Greg KH wrote:
> On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
> > -#include <asm/types.h>
> > +#include <stdint.h>
>
> Why?  I thought we were not including any glibc (or any other libc)
> header files when building the kernel?
Should be <linux/types.h>

> > -	__u16 bustype;
> > -	__u16 vendor;
> > -	__u16 product;
> > -	__u16 version;
> > +	uint16_t bustype;
> > +	uint16_t vendor;
> > +	uint16_t product;
> > +	uint16_t version;
>
> {sigh}  __u16 is _so_ much nicer, and tells the programmer, "Yes I know
> this variable needs to be the same size in userspace and in
> kernelspace."
I'll harp some more.
1. __u16 isn't really any nicer - its just what you (as a kernel programmer) are used to.
2. uint16_t is a *standard* type. Userspace programmer know it, even if they don't know Linux. 

We shouldn't arbitrarily invent new types that could be trivially done with 
standard types. Maybe we could retain existing usage for ABIs that are
unchanged from 2.0 days, but we certainly shouldn't be making the ABI
any worse.


-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Linus T. <tor...@tr...>]

On Tue, 30 Jul 2002, Greg KH wrote:

> On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
> > -#include <asm/types.h>
> > +#include <stdint.h>
>=20
> Why?  I thought we were not including any glibc (or any other libc)
> header files when building the kernel?

Indeed. This is unacceptable.

Especially as the standard types are total crap, and the u8 etc are a lot=
=20
more readable. People should realize:

 - the "int" is superfluous. Of _course_ it's an integer. If it was a=20
   floating point number, it would be fp16/fp32/fp64/fp80/whatever.
 - the "_t" is there only for namespace collisions, sane people can chose=
=20
   to ignore it.

What do you have left after you have removed the crap? Yup. u8, u16, etc.=
=20
And if you want to share with user space, there's=A0the long-accepted=20
namespace collision avoidance of prepending two underscores.

Fix it, Vojtech.

		Linus

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Greg KH <gr...@kr...>]

On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
> -#include <asm/types.h>
> +#include <stdint.h>

Why?  I thought we were not including any glibc (or any other libc)
header files when building the kernel?

> -	__u16 bustype;
> -	__u16 vendor;
> -	__u16 product;
> -	__u16 version;
> +	uint16_t bustype;
> +	uint16_t vendor;
> +	uint16_t product;
> +	uint16_t version;

{sigh}  __u16 is _so_ much nicer, and tells the programmer, "Yes I know
this variable needs to be the same size in userspace and in
kernelspace."

Just my two cents.

greg k-h

[patch] Remove superfluous code that snuck back in PPC merge

[Vojtech P. <vo...@su...>]

You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
'bk pull bk://linux-input.bkbits.net/linux-input' should work as well.

===================================================================

ChangeSet@1.531, 2002-07-30 22:04:17+02:00, Fra...@la...
  Hi Vojtech,
  some superflous keyboard stuff came back with the last PPC merge
  to Linus. This patch fixes that. Please apply.

 lopec_setup.c |   13 -------------
 1 files changed, 13 deletions(-)

diff -Nru a/arch/ppc/platforms/lopec_setup.c b/arch/ppc/platforms/lopec_setup.c
--- a/arch/ppc/platforms/lopec_setup.c	Tue Jul 30 22:17:44 2002
+++ b/arch/ppc/platforms/lopec_setup.c	Tue Jul 30 22:17:44 2002
@@ -34,14 +34,9 @@
 #include <asm/mpc10x.h>
 #include <asm/hw_irq.h>
 #include <asm/prep_nvram.h>
-#include <asm/keyboard.h>
 
 extern char saved_command_line[];
 extern void lopec_find_bridges(void);
-extern int pckbd_translate(unsigned char scancode, unsigned char *keycode,
-		char raw_mode);
-extern char pckbd_unexpected_up(unsigned char keycode);
-extern unsigned char pckbd_sysrq_xlate[128];
 
 /*
  * Define all of the IRQ senses and polarities.  Taken from the
@@ -384,14 +379,6 @@
 	ppc_md.find_end_of_memory = lopec_find_end_of_memory;
 	ppc_md.setup_io_mappings = lopec_map_io;
 
-#ifdef CONFIG_VT
-	ppc_md.kbd_translate = pckbd_translate;
-	ppc_md.kbd_unexpected_up = pckbd_unexpected_up;
-#ifdef CONFIG_MAGIC_SYSRQ
-	ppc_md.ppc_kbd_sysrq_xlate = pckbd_sysrq_xlate;
-#endif /* CONFIG_MAGIC_SYSRQ */
-#endif /* CONFIG_VT */
- 
 	ppc_md.time_init = todc_time_init;
 	ppc_md.set_rtc_time = todc_set_rtc_time;
 	ppc_md.get_rtc_time = todc_get_rtc_time;

===================================================================

This BitKeeper patch contains the following changesets:
1.531
## Wrapped with gzip_uu ##


begin 664 bkpatch22903
M'XL(`&CT1CT``]5486_3,!#]7/^*D_9Q-/'%3M)6*BILP"0F476,K\AQW"74
MJ2/;Z=8J/QZOA56`T#:$D$@BV3[[WEW>>\D)7#ME)X.W5JQWT55M-3F!"^/\
M9*!%YY4MA*PB:9H07A@3PG%E&A5OS!>O9!47J[A>MYTG87\NO*Q@HZR;##!B
M#Q&_;=5DL'CS[OKRU8*0Z13.*K&^45?*PW1*O+$;H4LW$[[29AWYT(IKE!?W
M9?N'HWU":1+N%'-&TZS'C/*\EU@B"HZJI`D?99RT8J/TS'5.17+W<W;(Q'&:
M4-:S/,M3<@X8I0R!)C'-8T8A22:43S`_I6%"X<C*[$<VX!1A2,EK^+O-GQ$)
M%S5\.I#[(JQ<(!M<URJ[U*9SL%+;P@A;@O/=<@E2A.W0U`IN:Q^8KA1HX3S,
MYV?0*'NC`H0W<%FO.Q?!QZIVT.XU6=9WRH7SPD<PUTHX!:)M]38B[X&-^"@G
M\Z-*9/C,BQ`J*'D9:G6Z<S,?<$QT6$1FIT41!GO3"QL<U+8R;K7P2V,;%VO3
M*OG9*=^UD?S&&E+$!%/L&4MPW)>295B6DLNDR)*4_UZE)Q8(DH21(^\SRCC?
M._2QS'OC_I.W^U[%B:80S\#-DXR.$%G`33,VWEL=?W4Z?]SI%(;(_@.K'XT>
MP)YH]8/@'V!H;_=/L.[\4>W_X',X9SD@.><(/,Q'.8R./TQ9*;ER73,MTIR/
-QV-)O@+`_N;.E04`````
`
end

-- 
Vojtech Pavlik
SuSE Labs

[patch] Fix suspend of the kseriod thread

[Vojtech P. <vo...@su...>]

You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
'bk pull bk://linux-input.bkbits.net/linux-input' should work as well.

===================================================================

ChangeSet@1.530, 2002-07-30 21:52:03+02:00, pa...@su...
  Move sleep_on() above refrigerator so that the kseriod thread
  in serio.c doesn't exit on suspend because of a pending signal.

 serio.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -Nru a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
--- a/drivers/input/serio/serio.c	Tue Jul 30 22:15:57 2002
+++ b/drivers/input/serio/serio.c	Tue Jul 30 22:15:57 2002
@@ -95,9 +95,9 @@
 
 	do {
 		serio_handle_events();
+		interruptible_sleep_on(&serio_wait); 
 		if (current->flags & PF_FREEZE)
 			refrigerator(PF_IOTHREAD);
-		interruptible_sleep_on(&serio_wait); 
 	} while (!signal_pending(current));
 
 	printk(KERN_DEBUG "serio: kseriod exiting");

===================================================================

This BitKeeper patch contains the following changesets:
1.530
## Wrapped with gzip_uu ##


begin 664 bkpatch22848
M'XL(`/WS1CT``[64:V_:,!2&/^-?<:1*VZJ*Q,Z5,#%U:W?3-@U1]3,RSH&X
MA!C9#JQ5?OR<E-&UT^BN2619;W)>G^/SQ$=P:5`/>V\TKVZ\"ZE+<@3OE+'#
M7LEKBWK&1>$)M7+R1"DG^X5:H;]15Q9%X<^6OJS6M27N_9A;4<`&M1GVF!?N
M%7N]QF%O\OKMY<>7$T)&(S@K>+7`"[0P&A&K](:7N3GEMBA5Y5F7BEFAY>VR
MS?[3)J`T<'?,TI#&2<,2&J6-8#EC/&*8TR`:)!'9)79J:H.>N'D8[V)9R+(P
M;,)!2F-R#LR+0PHT\&GJNTG`AG$PI.$)=2.%-=]@^<T,3ACT*7D%_S;E,R+@
MD]H@F!)Q/575LV/@LU;0.-=R@9J[!<$HL`6W;D!8NJ9)E;NY1IZ[>%E!)WD"
M<H6F>FH!OT@+RNFU66.5PPP%=W6`F@.'5I'5`HQ<5+STR`<(TR2-R?BN-Z3_
MFQ<AE%/RXI'=R;5L$?%%P;5_I:Z-E6+I[Y+_;L<B2N.&1DF6-"[Q>);A/!^D
M#)'?;\K>L./PUNB^7=OS+';3QOG&24?@@:#'F?S[$O:8VJTLY:*P7BVVOU9,
M$`6,15&T*Z8%./L!7_I3?-E_QM=A-E?Z`+JWR#ZDU'GL.&U9["K[#'V][1Z'
MUOA0Q_Z`U/=9"HST>K)R9YRNUU;.2ISN?\`GG?-TRZ4]?@[DG+F]9'=GG"A0
4+$V]&L48\T'(./D**"&1[T@%````
`
end

-- 
Vojtech Pavlik
SuSE Labs

Re: Customization of input drivers

[Vojtech P. <vo...@su...>]

On Mon, Jul 29, 2002 at 10:17:31PM -0400, Nathan Conrad wrote:

> Thanks for your reply. I accidently deleted your message after reading
> it.
> 
> I believe that the following would not be kernel bloat. Currently, the
> kernel does have keyboard remapping abilities (although I do not know
> the implementation details). Keyboard mapping _needs_ to be done at
> the kernel level because of the console layer. I need to be able to
> type with the dvorak layout soon after init is loaded. I do not want
> to run something like X in order to get a text console. If this
> remapping was done inside of input.c or evdev.c, this would kill two
> birds with one stone: keyboard re-mapping and mouse event re-mapping.

Well, no again. Keyboard remapping is done in keyboard.c (and not in the
input core) for a very good reason - the input core maps the
hardware-dependent scancodes to linux input event keycodes, which are
the same on every platform. Thus you can have the same keymap loaded
into keyboard.c to use the dvorak layout on a Sun, PC, Amiga, Mac, etc.

> Mouse mapping is not strictly needed here. It is just a nice side
> effect of moving mapping into input.c

But if you do it in userspace, you can also do all the nice gesture
stuff and sliders at the edge of touchpads and ... which you wouldn't be
able to do in the kernel generically enough and still pass the bloat
measure.

> Perhaps two mappings would be necessary: one for the scan codes->linux
> keycodes (which would be in the keyboard's driver) and another for
> linux codes->input events.
> 
> > I like for the left button sends a BTN_MIDDLE event while the touchpad
> > sends BTN_TOUCH. Is there a map somewhere that can change these button
> > mappings at runtime? Looking at mousdev.c, the BTN_TOUCH, BTN_LEFT,
> > and BTN_0 all send a mouse-0 event to the mouse device.... I would
> > like for my driver to be able to send a BTN_LEFT event when I click
> > the left button and have that converted somewhere into a mouse-1 event.
> 
> The touchpad itself reports when there has been a touch click or a
> drag. In order for this configuration to be done in userspace, there
> are two options:
> 
> 1) report the finger movements and use some complex, time-critical
> algorithm to determine if the user wants the touch to be translated
> into holding the mouse button down or if the user wants a click and
> then to move the mouse or a double click.

Actually time is not critical anymore with input drivers, because we
report precise timestamps to the userspace.

> 2) Let the hareware handle it, and add some new event such as BTN_TOUCH_DRAG.
> 
> I am not sure as to if kernel configuration or the second choice above
> would be the best.

I quite like option #2. I'd call it BTN_DRAG probably only. 

> > Another configuration flag that I would like to export to userspace is
> > if the user wants to be able to use the touchpad to click, and if so,
> > also be able to use a drag-lock. Many people that I know hate these
> > options....
> 
> > The ABS_* events seem to be directed towards toucdscreens and drawing
> > tablets. Is it the right thing to do to convert to REL_ events in
> > psmouse.c?
> 
> Now that I think about it, this point seems moot. The psmouse driver
> is the only place where it would have mattered. It is a hack and
> should die. 
> 
> On a side note, I like being able to mix multiple mouse devices. This
> should be done in gpm, etc.... What is supposed to happen when a
> device is hot-plugged? Will the hotplug daemon have to restart gpm
> (and supply the correct arguments) when a device is removed or added?

The hotplug agent (not a daemon, it's executed again on each hotplug
event) will do anything you want. Namely it can send a SIGUSR to gpm, or
connect to the X socket and explain the existence of a new device via
the XFree86-Misc extension.

> On the same Sony laptop, a key sometimes gets stuck down. It is almost
> always the shift key. The enter key started repeating right after I
> typed 'sudo halt'. My guess is that the key-release event is
> getting lost somewhere and the autorepeat (now done in software and
> not the keyboard that knows the correct state) is doing its job too
> well. Could you give me some pointers in debugging this? This happens
> in X and in the console.

There may be a bug in the autorepeat code. I think there is a small race
window which can cause the autorepeat continue even after the key is
released if the autorepeat timer code is running at the time the key is
being released.

I'll try to fix it today and if it still has problems on your machine
after that, we'll debug it there.

> Is there a mailing list somewhere to which I should be sending this
> message?

Cc:ed. Btw, linux-kernel could be interested, too.

-- 
Vojtech Pavlik
SuSE Labs

[patch] Input cleanups for 2.5.29 [2/2]

[Vojtech P. <vo...@su...>]

Hi!

You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
'bk pull bk://linux-input.bkbits.net/linux-input' should work as well.

===================================================================

ChangeSet@1.529, 2002-07-30 15:19:33+02:00, vo...@su...
  Use stdint.h types instead of __u16 et al in input.h, to make life
  easier for userspace people, as Brad Hards has suggested.


===================================================================

 input.h |   74 ++++++++++++++++++++++++++++++++--------------------------------
 1 files changed, 37 insertions(+), 37 deletions(-)

===================================================================

diff -Nru a/include/linux/input.h b/include/linux/input.h
--- a/include/linux/input.h	Tue Jul 30 15:21:51 2002
+++ b/include/linux/input.h	Tue Jul 30 15:21:51 2002
@@ -32,7 +32,7 @@
 #else
 #include <sys/time.h>
 #include <sys/ioctl.h>
-#include <asm/types.h>
+#include <stdint.h>
 #endif
 
 /*
@@ -41,9 +41,9 @@
 
 struct input_event {
 	struct timeval time;
-	unsigned short type;
-	unsigned short code;
-	unsigned int value;
+	uint16_t type;
+	uint16_t code;
+	int32_t value;
 };
 
 /*
@@ -57,10 +57,10 @@
  */
 
 struct input_id {
-	__u16 bustype;
-	__u16 vendor;
-	__u16 product;
-	__u16 version;
+	uint16_t bustype;
+	uint16_t vendor;
+	uint16_t product;
+	uint16_t version;
 };
 
 struct input_absinfo {
@@ -611,62 +611,62 @@
  */
 
 struct ff_replay {
-	__u16 length; /* Duration of an effect in ms. All other times are also expressed in ms */
-	__u16 delay;  /* Time to wait before to start playing an effect */
+	uint16_t length; /* Duration of an effect in ms. All other times are also expressed in ms */
+	uint16_t delay;  /* Time to wait before to start playing an effect */
 };
 
 struct ff_trigger {
-	__u16 button;   /* Number of button triggering an effect */
-	__u16 interval; /* Time to wait before an effect can be re-triggered (ms) */
+	uint16_t button;   /* Number of button triggering an effect */
+	uint16_t interval; /* Time to wait before an effect can be re-triggered (ms) */
 };
 
 struct ff_envelope {
-	__u16 attack_length;	/* Duration of attack (ms) */
-	__u16 attack_level;	/* Level at beginning of attack */
-	__u16 fade_length;	/* Duration of fade (ms) */
-	__u16 fade_level;	/* Level at end of fade */
+	uint16_t attack_length;	/* Duration of attack (ms) */
+	uint16_t attack_level;	/* Level at beginning of attack */
+	uint16_t fade_length;	/* Duration of fade (ms) */
+	uint16_t fade_level;	/* Level at end of fade */
 };
 
 /* FF_CONSTANT */
 struct ff_constant_effect {
-	__s16 level;	    /* Strength of effect. Negative values are OK */
+	int16_t level;	    /* Strength of effect. Negative values are OK */
 	struct ff_envelope envelope;
 };
 
 /* FF_RAMP */
 struct ff_ramp_effect {
-	__s16 start_level;
-	__s16 end_level;
+	int16_t start_level;
+	int16_t end_level;
 	struct ff_envelope envelope;
 };
 
 /* FF_SPRING of FF_FRICTION */
 struct ff_condition_effect {
-	__u16 right_saturation; /* Max level when joystick is on the right */
-	__u16 left_saturation;  /* Max level when joystick in on the left */
+	uint16_t right_saturation; /* Max level when joystick is on the right */
+	uint16_t left_saturation;  /* Max level when joystick in on the left */
 
-	__s16 right_coeff;	/* Indicates how fast the force grows when the
+	int16_t right_coeff;	/* Indicates how fast the force grows when the
 				   joystick moves to the right */
-	__s16 left_coeff;	/* Same for left side */
+	int16_t left_coeff;	/* Same for left side */
 
-	__u16 deadband;	/* Size of area where no force is produced */
-	__s16 center;	/* Position of dead zone */
+	uint16_t deadband;	/* Size of area where no force is produced */
+	int16_t center;	/* Position of dead zone */
 
 };
 
 /* FF_PERIODIC */
 struct ff_periodic_effect {
-	__u16 waveform;	/* Kind of wave (sine, square...) */
-	__u16 period;	/* in ms */
-	__s16 magnitude;	/* Peak value */
-	__s16 offset;	/* Mean value of wave (roughly) */
-	__u16 phase;		/* 'Horizontal' shift */
+	uint16_t waveform;	/* Kind of wave (sine, square...) */
+	uint16_t period;	/* in ms */
+	int16_t magnitude;	/* Peak value */
+	int16_t offset;	/* Mean value of wave (roughly) */
+	uint16_t phase;		/* 'Horizontal' shift */
 
 	struct ff_envelope envelope;
 
 /* Only used if waveform == FF_CUSTOM */
-	__u32 custom_len;	/* Number of samples  */	
-	__s16 *custom_data;	/* Buffer of samples */
+	uint32_t custom_len;	/* Number of samples  */	
+	int16_t *custom_data;	/* Buffer of samples */
 /* Note: the data pointed by custom_data is copied by the driver. You can
  * therefore dispose of the memory after the upload/update */
 };
@@ -677,22 +677,22 @@
    by the heavy motor.
 */
 struct ff_rumble_effect {
-	__u16 strong_magnitude;  /* Magnitude of the heavy motor */
-	__u16 weak_magnitude;    /* Magnitude of the light one */
+	uint16_t strong_magnitude;  /* Magnitude of the heavy motor */
+	uint16_t weak_magnitude;    /* Magnitude of the light one */
 };
 
 /*
  * Structure sent through ioctl from the application to the driver
  */
 struct ff_effect {
-	__u16 type;
+	uint16_t type;
 /* Following field denotes the unique id assigned to an effect.
  * If user sets if to -1, a new effect is created, and its id is returned in the same field
  * Else, the user sets it to the effect id it wants to update.
  */
-	__s16 id;
+	int16_t id;
 
-	__u16 direction;	/* Direction. 0 deg -> 0x0000 (down)
+	uint16_t direction;	/* Direction. 0 deg -> 0x0000 (down)
 					     90 deg -> 0x4000 (left)
 					    180 deg -> 0x8000 (up)
 					    270 deg -> 0xC000 (right)

===================================================================

This BitKeeper patch contains the following changesets:
1.529
## Wrapped with gzip_uu ##


begin 664 bkpatch20062
M'XL(`.^21CT``[5666_;.!!^MG[%`'WH&5FWCVR*'EYL@UY!LGT.:(F2V$BD
M2U)V4OC'[Y"2+<M-6NSE!*9YS#<?9[X9Z1%\453.1VOQ5=.T=![!.Z'T?*0:
M1=WT.\XOA<#YN!0U'7>GQLN;,>.K1CNX?T%T6L*:2C4?^6ZX7]%W*SH?7?[^
MQY</KR\=Y^P,WI:$%_2*:C@[<[20:U)EZA71926XJR7AJJ::N*FHM_NCV\#S
M`OR+_4GHQ<G63[QHLDW]S/=)Y-/,"Z)I$CG+DDC$6K)B)7CF<JI=TARC(((?
M&JQM.`N"F;,`WXV#&7C!V)N,0P_\>.[/YF'XW`OFG@?=;5]UL8#G/IQXSAOX
M;ZF_=5*3`U`Z8UR[;>`4,*XT)1F('*ZO&S\!#!NI<!ELY-WR!?*`FMQ0J%A.
M$802Q:B$7$A`PE*M2$IA1<6JHB^`*'@C$>Z=B1.4.%5-45#TD;G.>PBG$R]V
M+OH4.2=_\^,X'O&<E[\(#N-IU61T7#'>W(Z[FQP&:A;YVR2*_.DV#X/E-`B3
M)*<>)=[T.!T_P[*9]F>AMPVB"6;:J._>X[]6XK]@_(`J?\7;(*-8HMG$*M2/
M?A"H]Y!`PPF<A)/_1:(?Q9H:Q0UE:K33AO@SG,B-_4<M7-P?[7\@JD48@^^<
MV^]''2C\MB/QTEE$$83.>93@]ZC!13^YUI;;Z<$\%9F9XS0,<(JA:7"^2#R(
MG/,DQ._^[+)1Q^9KRC,A#U=64F1-JH>'I&*"&UA,68"X?HQ#?Z"BO-#E*8R?
MP:*11.-A4]V$`\USFFI3V[5RX755@=`EEK)F-78"(BE6OA)`;U>2*D6S]B0\
M&Q^@9[0B=Z=@T/]$,Y.J#6%X'8H-H<L<D<@<CS%>'+A%&*0\LY0#;T!YV6B-
M5P(+^ZFIET@**;?+H"7#%B)_0.OM<:1&B*</T>KM4ORYI"#I20>+UWQ2JZ<M
MO2"RF0HF@U01K4EZ<]T%=G0<6+N[![G';$TK:_7!_,)E)%`PSLV%>ON!:4XR
M^I`_LW>/M\[D!U^HJ;V5O6,8&*6WPZ@7C36$-@576EK?QK"-FPN?:($4L#BM
MJENY?'[?04YM5D.3W#VDU4''J%]%.KNU11+%U@ZKZE`-F)=27RNBNTO;K'XD
MMRU)V)24PU=QIS3#L#$%1B(E;<V&,:EH/@3Z*1+?(1FS]F+1U,;*#J,AOU1@
M9&RHSWG&4J(Q)J788*"5MB@H/'PP%E)L5.L)%Q$R]BRD'48#HCWB%:FM?<M$
ML5WJXL#&*PX'\<KP^;TD/&M-V7=J524I,6XQ2UQT7#!6;4-!S9LX[=L6-?5C
MS2^$8CNA&5SX+OC.^0QB=(YM+#YPOB%K4V*UM7[/6K&917BB&,<W`O6M02ZN
MZQ[I=845+5K.?9O9;=:DX$QC#VY)47+3RFYP2.2YHMJ>^$BQK-L3>_=2-$59
MW1V[Q7<21#5&C]\)R?!^FE2/095LE_2D57,RVT79-O,4^[6H35%:CWV74J3&
M5Q\%:#SJR3WKSF=$$VOPIL%"&AA89U//.IOZ@Y0J+04OKOLP=,KMI@;%2*RD
M9'T'M<#'\/"6&XS8P/I^^\J6S#[#TU;M=CA^R"V266AW[;"_)LOL5MQNQ0/#
MC$GL'*;N;`O;S5SP4%H%G+P$[];##SS)Q(8_[5_RTY*F-ZJISY8DRF=YD#M_
)`4P*E3<_#```
`
end
-- 
Vojtech Pavlik
SuSE Labs