linuxconsole-dev

Re: web site organization

[James S. <jsi...@tr...>]

> I've just started trying to get up to speed with where things are on 
> linuxconsole. I'm glad to see the input work being combined with James' 
> work.

Yeap!!! Also alot of improvements have happened over time to the core
code. Still there is alot to do. Right now tho the major step is to push
the input stuff and the new fbdev api into the standard kernel/

> Right now the web site is confusing. The highly-polished input drivers 
> pages appear to have been thrown together with the linuxconsole pages 
> hastily. Some pages use the sourceforge project navigation and some 
> don't. It makes the basic message hard to follow.

Yes I did that and yes it is a piece of junk. I suck at web design. If
you like to cleanup and make a nice web site I would be really happy :-) 
 
> Is there a direction everyone would like the docs to go? Can I help?

Of course you can help. 

> I have been correcting typos here and there in the docs and I think 
> continuing to deal with docs for a while will also help me get a feel 
> for where I can help out in the project.

Yeap! It also forces me to explain what I have done which is needed.

Re: First cut at Linux HID programming guide available

[James S. <jsi...@tr...>]

> I have put up my working draft on 
> http://www.frogmouth.net/hid-doco/linux-hid.html

Thanks :-) Very good read!!

> In the longer term, I'd like to move it over to one or both of the USB or 
> Linuxconsole sites, but it is so rough, I don't think that is appropriate 
> yet.

Great!!! Much better than what I could do. 

web site organization

[Brad M. <bmi...@tu...>]

hi,

I've just started trying to get up to speed with where things are on 
linuxconsole. I'm glad to see the input work being combined with James' 
work.

Right now the web site is confusing. The highly-polished input drivers 
pages appear to have been thrown together with the linuxconsole pages 
hastily. Some pages use the sourceforge project navigation and some 
don't. It makes the basic message hard to follow.

Is there a direction everyone would like the docs to go? Can I help?

I have been correcting typos here and there in the docs and I think 
continuing to deal with docs for a while will also help me get a feel 
for where I can help out in the project.

thanks
Brad

2.4.xx backport

[Aivils S. <Aiv...@un...>]

>There are a lot of changes to the version in 2.4.19-pre7. Are you feeding
>changes to just CVS, CVS and 2.5 or CVS, 2.4 and 2.5? Is there plans to
run a
>backport later, or is 2.4 going to stagnate?
>
>I am just bringing up a box that I can afford to run a risky kernel on
(like
>2.5.X-preY :), so I will soon be able to play with various combos of 2.4,
2.5
>and 2.5+CVS.
>
>I can maybe do some patches for the input system for 2.4 if you just need
>grunt work.
>
>Brad

Unfortunately I have no plans.
I as user use my own linux kernel based on ruby.
I publice this in
http://startx.times.lv/bstreet.tar.bz2

(my old host startx.yo.lv die)

This is 11-MAR-2002 snapshoot of ruby CVS patched by me to allow
run 2.4.18.
I don't have lots of inputs devices and test only AT keyboards,
serial mouse, USB keyboard, USB mouse.

I hope this will help other non-developers run linux-ruby.

Aivils Stoss

Re: evdev types

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

On Mon, Apr 22, 2002 at 06:40:25PM +1000, Brad Hards wrote:
> On Mon, 22 Apr 2002 18:26, Vojtech Pavlik wrote:
> > On Mon, Apr 22, 2002 at 06:19:29PM +1000, Brad Hards wrote:
> > > On Mon, 22 Apr 2002 17:22, Vojtech Pavlik wrote:
> > > > EVIOCGBUS? What's that?
> > >
> > > Beats me:
> > > $ grep EVIOCGBUS include/linux/input.h
> > > #define EVIOCGBUS               _IOR('E', 0x07, short[4])              
> > > /* get bus address */
> >
> > Humm, don't have it in my current version, sorry. Latest version
> > (without your patches still) attached. (Note the interface version isn't
> > changed yet in it, but that's a mistake).
> I'm looking at the 2.4.19-pre7 from Marcelo, which is what I guess most 
> developers are working on. The version in 2.4.19-pre7 is
> 
> $Id: input.h,v 1.34 2001/05/28 09:06:44 vojtech Exp $
> 
> There are a lot of changes to the version in 2.4.19-pre7. Are you feeding 
> changes to just CVS, CVS and 2.5 or CVS, 2.4 and 2.5? Is there plans to run a 
> backport later, or is 2.4 going to stagnate?

The plan is to do a partial backport later, right now the most recent
stuff is in the CVS, being fed into 2.5 from CVS gradually.

> I am just bringing up a box that I can afford to run a risky kernel on (like 
> 2.5.X-preY :), so I will soon be able to play with various combos of 2.4, 2.5 
> and 2.5+CVS.
> 
> I can maybe do some patches for the input system for 2.4 if you just need 
> grunt work.

It would be nice, if you could. I'm rather low on time right now (should
be better after a couple weeks), because of other projects (robotic cup,
wedding, ...).

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

[Johann D. <jo...@do...>]

Brad Hards wrote:

> On Mon, 22 Apr 2002 18:26, Vojtech Pavlik wrote:

>>Humm, don't have it in my current version, sorry. Latest version
>>(without your patches still) attached. (Note the interface version isn't
>>changed yet in it, but that's a mistake).
>>
> I'm looking at the 2.4.19-pre7 from Marcelo, which is what I guess most 
> developers are working on. The version in 2.4.19-pre7 is
> 
> $Id: input.h,v 1.34 2001/05/28 09:06:44 vojtech Exp $
> 
> There are a lot of changes to the version in 2.4.19-pre7. Are you feeding 
> changes to just CVS, CVS and 2.5 or CVS, 2.4 and 2.5? Is there plans to run a 
> backport later, or is 2.4 going to stagnate?
> 
> I am just bringing up a box that I can afford to run a risky kernel on (like 
> 2.5.X-preY :), so I will soon be able to play with various combos of 2.4, 2.5 
> and 2.5+CVS.
> 
> I can maybe do some patches for the input system for 2.4 if you just need 
> grunt work.
> 
> Brad
> 
> 
> 
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> 

I maintain an unofficial iforce patch, which happens to contain a more 
recent version of input.h (1.63). This patch is against 2.4.17, but it 
should apply with very little efforts to the latest 2.4 kernel.
If you want, you can get it here:

http://www.docs.uu.se/~johannd/projects/ff/patch-2.4.17-020408.bz2

-- 
Johann Deneux

Re: evdev types

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

On Mon, 22 Apr 2002 18:26, Vojtech Pavlik wrote:
> On Mon, Apr 22, 2002 at 06:19:29PM +1000, Brad Hards wrote:
> > On Mon, 22 Apr 2002 17:22, Vojtech Pavlik wrote:
> > > EVIOCGBUS? What's that?
> >
> > Beats me:
> > $ grep EVIOCGBUS include/linux/input.h
> > #define EVIOCGBUS               _IOR('E', 0x07, short[4])              
> > /* get bus address */
>
> Humm, don't have it in my current version, sorry. Latest version
> (without your patches still) attached. (Note the interface version isn't
> changed yet in it, but that's a mistake).
I'm looking at the 2.4.19-pre7 from Marcelo, which is what I guess most 
developers are working on. The version in 2.4.19-pre7 is

$Id: input.h,v 1.34 2001/05/28 09:06:44 vojtech Exp $

There are a lot of changes to the version in 2.4.19-pre7. Are you feeding 
changes to just CVS, CVS and 2.5 or CVS, 2.4 and 2.5? Is there plans to run a 
backport later, or is 2.4 going to stagnate?

I am just bringing up a box that I can afford to run a risky kernel on (like 
2.5.X-preY :), so I will soon be able to play with various combos of 2.4, 2.5 
and 2.5+CVS.

I can maybe do some patches for the input system for 2.4 if you just need 
grunt work.

Brad

Re: evdev types

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

On Mon, Apr 22, 2002 at 06:19:29PM +1000, Brad Hards wrote:
> On Mon, 22 Apr 2002 17:22, Vojtech Pavlik wrote:
> > On Mon, Apr 22, 2002 at 10:04:54AM +1000, Brad Hards wrote:
> <snip>
> > You need a way to read the initial values of all absolute valuators
> > before you get any events. You may get none if the valuator doesn't
> > ever change.
> My original thinking was "Then why does the valuator matter?", but I thought 
> about it some more. A dial that indicates volume is a good example of one 
> that matters. Too much joystick thinking...

Even on joystick you have the throttle, which doesn't return into center
position automatically.

> > > * finding out about the device identity (EVIOCGNAME and EVIOCGID, maybe
> > > EVIOCGBUS if it works)
> >
> > EVIOCGBUS? What's that?
> Beats me:
> $ grep EVIOCGBUS include/linux/input.h
> #define EVIOCGBUS               _IOR('E', 0x07, short[4])               /* get 
> bus address */

Humm, don't have it in my current version, sorry. Latest version
(without your patches still) attached. (Note the interface version isn't
changed yet in it, but that's a mistake).

> I just want it to work or go away. Anyone owning up to putting it in 
> <linux/input.h>?
> 
> > > * finding out about the device features (EVIOCGBIT and EVIOCGABS)
> >
> > Add EVIOCGKEY, EVIOCGLED and EVIOCGSND to that.
> OK, added to list.
> 
> > > I think that the first element (now ->curr_value) is a different concept
> > > to the programmer compares to the rest of the features identified with
> > > EVIOCGABS.
> >
> > It's also a value you need before you start reading the events, so it's
> > handy there.
> With further thought, I think we keep it in the same ioctl. Delete the comment 
> marks. Might help stop binary breakage too.

Yes. That's right.

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

On Mon, 22 Apr 2002 17:22, Vojtech Pavlik wrote:
> On Mon, Apr 22, 2002 at 10:04:54AM +1000, Brad Hards wrote:
<snip>
> You need a way to read the initial values of all absolute valuators
> before you get any events. You may get none if the valuator doesn't
> ever change.
My original thinking was "Then why does the valuator matter?", but I thought 
about it some more. A dial that indicates volume is a good example of one 
that matters. Too much joystick thinking...

> > * finding out about the device identity (EVIOCGNAME and EVIOCGID, maybe
> > EVIOCGBUS if it works)
>
> EVIOCGBUS? What's that?
Beats me:
$ grep EVIOCGBUS include/linux/input.h
#define EVIOCGBUS               _IOR('E', 0x07, short[4])               /* get 
bus address */

I just want it to work or go away. Anyone owning up to putting it in 
<linux/input.h>?

> > * finding out about the device features (EVIOCGBIT and EVIOCGABS)
>
> Add EVIOCGKEY, EVIOCGLED and EVIOCGSND to that.
OK, added to list.

> > I think that the first element (now ->curr_value) is a different concept
> > to the programmer compares to the rest of the features identified with
> > EVIOCGABS.
>
> It's also a value you need before you start reading the events, so it's
> handy there.
With further thought, I think we keep it in the same ioctl. Delete the comment 
marks. Might help stop binary breakage too.

Brad

Re: evdev types

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

On Mon, Apr 22, 2002 at 10:04:54AM +1000, Brad Hards wrote:

> On Wed, 17 Apr 2002 16:27, Brad Hards wrote:
> > On Mon, 15 Apr 2002 23:44, Vojtech Pavlik wrote:
> > <snip>
> >
> > > May I suggest one more change?
> > >
> > > dev->dinfo.bustype to dev->id.bus
> > > dev->devinfo.id_vendor ro dev->id.vendor
> >
> > Mostly done. I kept bustype, because it is more descriptive, and because it
> > helps the assignment operators line up :)
> I have done a similar change to the EVIOCGABS ioctl. It now returns 
> input_absinfo, rather than int[5]. Patches against evtest and 2.4.19-pre7 are 
> attached, including the previous patch (so you only need these ones). Let me 
> know if you'd rather an incremental patch.
> 
> I have commented out the current value element. I am unconvinced that it is an 
> appropriate thing to return from this ioctl.

You need a way to read the initial values of all absolute valuators
before you get any events. You may get none if the valuator doesn't
ever change.

> My tutorial works in stages -
> * finding out things about the event system (EVIOCGVERSION)
> * finding out about the device identity (EVIOCGNAME and EVIOCGID, maybe 
> EVIOCGBUS if it works)

EVIOCGBUS? What's that?

> * finding out about the device features (EVIOCGBIT and EVIOCGABS)

Add EVIOCGKEY, EVIOCGLED and EVIOCGSND to that.

> * getting information from the device (read())
> * sending information to the device (write())
> * modifying the device behaviour (eg EVIOCGREP and EVIOCSREP)
> 
> I think that the first element (now ->curr_value) is a different concept to 
> the programmer compares to the rest of the features identified with 
> EVIOCGABS. 

It's also a value you need before you start reading the events, so it's
handy there.

> If it is important that that value is available before someone does anything 
> to the device, then another ioctl is probably appropriate.

Might work as well.

> PLEASE NOTE:
> I need to know if these patches are going to be accepted and pushed into the 
> main-line kernels, because they affect the documentation. Please let me know 
> ASAP which way you are going to go.

They will.
 

-- 
Vojtech Pavlik
SuSE Labs

First cut at Linux HID programming guide available

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

I have put up my working draft on 
http://www.frogmouth.net/hid-doco/linux-hid.html

This covers HIDDEV (only a little, at this stage) and event interfaces (a bit 
more complete - should be at least partly usable). Also, some of the event 
stuff pre-supposes getting a couple of patches accepted - it won't all work 
with vanilla 2.4.19-pre7.

You can also get PS (http://www.frogmouth.net/hid-doco/Linux-HID.ps) and PDF 
(http://www.frogmouth.net/hid-doco/Linux-HID.pdf).

In the longer term, I'd like to move it over to one or both of the USB or 
Linuxconsole sites, but it is so rough, I don't think that is appropriate 
yet.

Please don't /. the server, since it is download limited. However if you have 
time to look at it, and have any comments on the approach or content, I'd be 
keen to hear them.

Brad

Re: evdev types

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

On Mon, 22 Apr 2002 10:04, Brad Hards wrote:
> On Wed, 17 Apr 2002 16:27, Brad Hards wrote:
> > On Mon, 15 Apr 2002 23:44, Vojtech Pavlik wrote:
> > <snip>
> >
> > > May I suggest one more change?
> > >
> > > dev->dinfo.bustype to dev->id.bus
> > > dev->devinfo.id_vendor ro dev->id.vendor
> >
> > Mostly done. I kept bustype, because it is more descriptive, and because
> > it helps the assignment operators line up :)
>
> I have done a similar change to the EVIOCGABS ioctl. It now returns
> input_absinfo, rather than int[5]. Patches against evtest and 2.4.19-pre7
> are attached, including the previous patch (so you only need these ones).
Really attached, this time

> Let me know if you'd rather an incremental patch.
>
> I have commented out the current value element. I am unconvinced that it is
> an appropriate thing to return from this ioctl. My tutorial works in stages
> - * finding out things about the event system (EVIOCGVERSION)
> * finding out about the device identity (EVIOCGNAME and EVIOCGID, maybe
> EVIOCGBUS if it works)
> * finding out about the device features (EVIOCGBIT and EVIOCGABS)
> * getting information from the device (read())
> * sending information to the device (write())
> * modifying the device behaviour (eg EVIOCGREP and EVIOCSREP)
>
> I think that the first element (now ->curr_value) is a different concept to
> the programmer compares to the rest of the features identified with
> EVIOCGABS.
>
> If it is important that that value is available before someone does
> anything to the device, then another ioctl is probably appropriate.
>
> PLEASE NOTE:
> I need to know if these patches are going to be accepted and pushed into
> the main-line kernels, because they affect the documentation. Please let me
> know ASAP which way you are going to go.
>
> Brad

Re: evdev types

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

On Wed, 17 Apr 2002 16:27, Brad Hards wrote:
> On Mon, 15 Apr 2002 23:44, Vojtech Pavlik wrote:
> <snip>
>
> > May I suggest one more change?
> >
> > dev->dinfo.bustype to dev->id.bus
> > dev->devinfo.id_vendor ro dev->id.vendor
>
> Mostly done. I kept bustype, because it is more descriptive, and because it
> helps the assignment operators line up :)
I have done a similar change to the EVIOCGABS ioctl. It now returns 
input_absinfo, rather than int[5]. Patches against evtest and 2.4.19-pre7 are 
attached, including the previous patch (so you only need these ones). Let me 
know if you'd rather an incremental patch.

I have commented out the current value element. I am unconvinced that it is an 
appropriate thing to return from this ioctl. My tutorial works in stages -
* finding out things about the event system (EVIOCGVERSION)
* finding out about the device identity (EVIOCGNAME and EVIOCGID, maybe 
EVIOCGBUS if it works)
* finding out about the device features (EVIOCGBIT and EVIOCGABS)
* getting information from the device (read())
* sending information to the device (write())
* modifying the device behaviour (eg EVIOCGREP and EVIOCSREP)

I think that the first element (now ->curr_value) is a different concept to 
the programmer compares to the rest of the features identified with 
EVIOCGABS. 

If it is important that that value is available before someone does anything 
to the device, then another ioctl is probably appropriate.

PLEASE NOTE:
I need to know if these patches are going to be accepted and pushed into the 
main-line kernels, because they affect the documentation. Please let me know 
ASAP which way you are going to go.

Brad

Re: [Libff-devel] Sidewinder FF driver

[Johann D. <joh...@la...>]

James Simmons wrote:

> 
>>Are we using the same kernel version ? I do have link-time errors too, 
>>but not the same ones. In my case, handle_scancode isn't defined in any 
>>object linked to bzImage.
>>I was using Linus' 2.5.7 with files from the linuxconsole CVS in this 
>>attempt.
>>
> 
> handle_scancode. That shouldn't be used anymore. You wouldn't by change be
> enabling keybdev.c in drivers/input. For ruby we don't need it anymore.
> 

Indeed, I was enabling keybdev.c. But if I don't, the only way to access 
the keyboard is through /dev/event, then ? I guess none of my 
applications do that.
The current behaviour (with keybdev disabled) is that I can't log-in (in 
text mode), neither can I when X is running. In both cases, the keyboard 
is non-responsive.

-- 
Johann Deneux

EVIOCGBUS ioctl?

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

This ioctl() is defined in <linux/input.h>, but I can't see how it is 
implemented in drivers/input/evdev.c (checked 2.4.19-pre7, and CVS). My 
sample app is returning -EINVAL to the ioctl call.

Can someone identify whether this is still to be implemented, or give me a 
pointer to where it works, and what the eight bytes (short[4]) that the bus 
address comes back in are?

If it is still to be implemented, what is is supposed to provide? If there is 
no semantics, can it be removed (or at least commented out of the header 
file?

Brad

Re: evdev types

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

On Thu, Apr 18, 2002 at 05:43:58PM +1000, Brad Hards wrote:
> On Thu, 18 Apr 2002 17:33, Vojtech Pavlik wrote:
> <snip>
> > > Why use long arrays for the bitfields? Why not byte arrays? This seems
> > > like the easiest way to clean up your concerns with 32/64 split systems,
> > > and also to clean up this.
> >
> > Because set_bit/test_bit and friends all operate on longs.
> Ah.
> 
> > Regarding the two bytes/four bytes stuff we can:
> >
> > 1) Remove the warning and all will work OK
> >
> > or
> >
> > 2) Don't warn if the valid bits actually fit
> I like 2. Do you want a patch?

Send it if you have the time to do it. Right now, I don't.

> > And for /proc and hotplug I think we can specify that we'll always use
> > 32-bit numbers (we currently use longs (%lx), where the size varies
> > between 32 and 64-bit kernels on the same system).
> You can fix that - I'm not doing 2.5 yet :)

I will. It's not tough.

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

On Thu, 18 Apr 2002 17:33, Vojtech Pavlik wrote:
<snip>
> > Why use long arrays for the bitfields? Why not byte arrays? This seems
> > like the easiest way to clean up your concerns with 32/64 split systems,
> > and also to clean up this.
>
> Because set_bit/test_bit and friends all operate on longs.
Ah.

> Regarding the two bytes/four bytes stuff we can:
>
> 1) Remove the warning and all will work OK
>
> or
>
> 2) Don't warn if the valid bits actually fit
I like 2. Do you want a patch?

> And for /proc and hotplug I think we can specify that we'll always use
> 32-bit numbers (we currently use longs (%lx), where the size varies
> between 32 and 64-bit kernels on the same system).
You can fix that - I'm not doing 2.5 yet :)

Brad

Re: evdev types

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

On Thu, Apr 18, 2002 at 05:23:51PM +1000, Brad Hards wrote:
> On Wed, 17 Apr 2002 23:18, Vojtech Pavlik wrote:
> > On Wed, Apr 17, 2002 at 09:56:05PM +1000, Brad Hards wrote:
> <snip>
> > > Ah, I think I have it now. For
> > >
> > > ioctl(a, EVIOCGBIT(b, c), d)
> > >
> > > a is the file descriptor for the event device you want
> > >
> > > b is the type of descriptor bitfield to return
> > > 	0 for the type of descriptors that are used
> > > 	EV_KEY for the key bitfield
> > > 	EV_REL for the relative axes bitfield
> > > 	EV_ABS for the absolute axes bitfield
> > > 	EV_MSC for the miscellaneous bitfield (not used yet?)
> > > 	EV_LED for the bright lights bitfield
> > > 	EV_SND for the loud noises bitfield
> > > 	EV_REP for the repeat function bitfield (not used yet?)
> > > 	EV_FF for the force feedback bitfield
> > >
> > > c is the maximum number of bits to return
> > > 	If the number of bits available is greater, then you get a warning
> > > message
> >
> > Bytes.
> Actually, it is more complex than that. The code all assumes that there is a 
> long on the other end.
> So my sample code for reading LED values (simplified here for shortness, let 
> me know if you want it all):
> <programlisting>
>   uint8_t led_bitmask[LED_MAX/8 + 1];
> ...
>   ioctl(fd, EVIOCGBIT(EV_LED, sizeof(led_bitmask)), led_bitmask)
> </programlisting>
> 
> is hitting the truncation check, because I'm only providing two bytes, and it 
> wants to return four (long, on ix86). Makes a mess in my syslog, and yet it 
> is reasonable from an application point of view, since the led_bitmask 
> doesn't really need to be an array - I could have just malloc'd it, and it is 
> big enough to hold all valid bit settings.
> 
> Why use long arrays for the bitfields? Why not byte arrays? This seems like 
> the easiest way to clean up your concerns with 32/64 split systems, and also 
> to clean up this.

Because set_bit/test_bit and friends all operate on longs.

Regarding the two bytes/four bytes stuff we can:

1) Remove the warning and all will work OK

or

2) Don't warn if the valid bits actually fit

And for /proc and hotplug I think we can specify that we'll always use
32-bit numbers (we currently use longs (%lx), where the size varies
between 32 and 64-bit kernels on the same system).

> > > OK, my only question now is "how do you get the descriptor bitfield for
> > > EV_RST?"
> >
> > There is none. There are no bits for EV_RST, it's only one event in its
> > own class.

> OK. This also applies to EV_REP?

Yes.

> Thanks again for all your help.

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

On Wed, 17 Apr 2002 23:18, Vojtech Pavlik wrote:
> On Wed, Apr 17, 2002 at 09:56:05PM +1000, Brad Hards wrote:
<snip>
> > Ah, I think I have it now. For
> >
> > ioctl(a, EVIOCGBIT(b, c), d)
> >
> > a is the file descriptor for the event device you want
> >
> > b is the type of descriptor bitfield to return
> > 	0 for the type of descriptors that are used
> > 	EV_KEY for the key bitfield
> > 	EV_REL for the relative axes bitfield
> > 	EV_ABS for the absolute axes bitfield
> > 	EV_MSC for the miscellaneous bitfield (not used yet?)
> > 	EV_LED for the bright lights bitfield
> > 	EV_SND for the loud noises bitfield
> > 	EV_REP for the repeat function bitfield (not used yet?)
> > 	EV_FF for the force feedback bitfield
> >
> > c is the maximum number of bits to return
> > 	If the number of bits available is greater, then you get a warning
> > message
>
> Bytes.
Actually, it is more complex than that. The code all assumes that there is a 
long on the other end.
So my sample code for reading LED values (simplified here for shortness, let 
me know if you want it all):
<programlisting>
  uint8_t led_bitmask[LED_MAX/8 + 1];
...
  ioctl(fd, EVIOCGBIT(EV_LED, sizeof(led_bitmask)), led_bitmask)
</programlisting>

is hitting the truncation check, because I'm only providing two bytes, and it 
wants to return four (long, on ix86). Makes a mess in my syslog, and yet it 
is reasonable from an application point of view, since the led_bitmask 
doesn't really need to be an array - I could have just malloc'd it, and it is 
big enough to hold all valid bit settings.

Why use long arrays for the bitfields? Why not byte arrays? This seems like 
the easiest way to clean up your concerns with 32/64 split systems, and also 
to clean up this.


> > OK, my only question now is "how do you get the descriptor bitfield for
> > EV_RST?"
>
> There is none. There are no bits for EV_RST, it's only one event in its
> own class.
OK. This also applies to EV_REP?

Thanks again for all your help.

Brad

Re: [Linux-fbdev-devel] Fbdev Bitkeeper repository

[M. R. B. <mr...@0x...>]

* Larry McVoy <lm...@bi...> on Wed, Apr 17, 2002:

>=20
> I think BK can help you and you are so stuck on one way of doing things
> that you are ignoring that possibility.  That's OK with me so long as
> it is just you, but you're posting in a public forum, to a group of
> people that I'm trying to help, and as long as you do, I'll be here,
> annoying as heck, explaining why you are wrong.  I'm not saying that you
> are wrong about BK drop-ins, you're right about that.  We're fixing it as
> fast as we can, it's in my top 3 work items right now.  In the meantime,
> if you poked around, there are lots of ways to use BK and I'm 99% sure
> you could find one that would result in less work overall for you than
> what you are doing now.  I don't care if *you* find one, I care if=20
> others find one.  We're trying to maximize productive work for the
> largest number of people, and I find your posts counterproductive to
> that goal.

The cool thing is, since the linuxconsole drop-in wasn't going anywhere, I
can move on to more useful pursuits instead of going back and forth with yo=
u.
If you want to spend your time denegrating other SCMs and people that don't
subscribe to your divine development tenets, more power to you.  I've
learned enough from this thread to not waste time arguing with you.  Next
time someone says something about Bitkeeper that I happen to agree or
disagree with, do you suppose I should just e-mail them privately?  Or
should I post here to make sure it gets under your scrutinizing eye?

Apologies to those who read this God awful thread without hitting Control-D
first :P.

M. R.

Re: [Linux-fbdev-devel] Fbdev Bitkeeper repository

[Larry M. <lm...@bi...>]

On Wed, Apr 17, 2002 at 08:52:15AM -0500, M. R. Brown wrote:
> > > For the LinuxSH project, we moved from tracking the full kernel tree (via
> > > CVS) to a drop-in tree structure mainly because of the difficulty in
> > > tracking all upstream kernel changes at once.  It wasn't really related to
> > > what CVS did or did not offer.
> > 
> > Disagree.  CVS sucks at tracking an external source of change while
> > maintaining your own changes at the same time, in the same tree.
> > It really sucks at that, you are forced into a broken branching model
> > with awful merge characteristics.  Try the same thing with BK, it's
> > a lot nicer, most stuff just automerges, and the stuff that doesn't
> > only needs to be merged once.  Your claim that it isn't about CVS
> > doesn't make much sense when CVS forces you to split your subtree
> > out.  Having an _option_ to do that is one thing, being forced to
> > do it is another.
> 
> I'd hate to sound like I'm trolling or being a broken record.  But I don't
> currently have that option with BK.  This is the option I want, to be able
> to not have to worry about pulling all changes or being able to cordon off
> only the bit I want/need to work with.  

Here's how you do it with BK.

    a) pick a baseline that you want.  Like 2.4 or 2.5.  clone it.
    b) put your changes on top of it.
    c) for each tree to which you want to apply your changes, clone it,
       and then pull from your tree.

Just go try that for a month's worth of changes and then tell me if it
isn't easier for you.

The deal is that you are trying to take your style of working, which as
far as I can tell, is based on CVS being broken, and insisting on that
style.  If you really want to work that way, you can, you are just losing
a lot in the process.  But whatever.  If you want to maintain a drop in
tree from a BK tree, then just check out the part of the tree you want
and plop the files into CVS.  Cort exported subsets of the trees as
patches for Linus for 2 years, it works.

> > And if that tree has changes in the files that you are "dropping in"?
> > You just stomped on them.  Or you are left with an even more broken
> > merge model than CVS.  And what about file renames.
> 
> When my drop-in tree file changes upstream, I'll find out in the next
> upstream sync.  Obviously if my drop-in tree is current, that file hasn't
> changed yet.  File renames are broken, but I never pretended they weren't.  I
> guess what you're saying is it comes down to me weighing out feature-rich
> set vs. feature-less set, where BK is the former, and I should expect to have
> to sacrifice my entire development model (drop-in trees, not CVS) for the
> bloated model that BK currently *enforces* (see your above paragraph about
> having the option).

That "bloated model" makes all the hard aspects of your model go away.
So you are trading off your model against your time.  That's the whole
point.  For the cost of some local storage, you get some of your time
back to do useful work.  Read that again.  That's the whole point.
An SCM tool is supposed to *save you time*.  What you are doing is
replacing missing features by you manually fixing up the places where
your tools didn't work.

You'd have a strong point if the model that BK was using wasted your time,
but you haven't made that case.

> > Part of the problem I have is that
> > you are, in a public forum, saying that BK is this and that, based on your
> > perceptions from 2 years ago when you said you used it on the ppc tree.
> 
> Nope, I said that based on what I read at www.bitkeeper.com, BK didn't
> support drop-in trees *today*.  I said that the last time I actively used
> the tool was 2 years ago, but I haven't had a reason to use it since then.
> In a public forum, which you use to promote sales and use of your product, I

OK, one day this might not be true, but so far, we haven't made a dime
off the people in this forum.  The people reading this forum don't spend
money, they write/read code.  The fact that this forum has not been
a money make for us has been true for 4 years.  I'm not sure how many
years it needs to be true before it might occur to you that the reason
I post here about BK is for some other reason than to make money.

BK is my primary way, these days, of trying to help out with the kernel.
I'd like it to help as many people as possible because I like Linux.
All of these posts are focussed on one thing: making people more productive
while doing development on the kernel.  Your posts annoyed me because they
made it sound like BK slows you down.  In the case you are talking about,
I think the opposite is true.  You might think that too if you actually 
tried it.

> When I decide to start and maintain the "linux toaster
> driver", I pull out the source I need from mainline, and setup my drop-in
> tree from that and my new imports.  The BK way to do it is to simply "clone
> the master" and work from that.  Not a drop-in.

So what?  Do a hardlinked clone, it costs you nothing, and do your work
in there.  BK will solve all the merge/rename problems that are inevitable
and you can focus on your work.

> Are you
> saying the only way for me to evaluate a tool (one that I haven't used in
> ages) is to use it?  

Yes.  Just like the only way to know how an application performs on a
platform is to run it.  Documentation, peer reviews, the words out of
my mouth, they are all like benchmark results, they are noise compared
to you actually trying to do what you want to do.

> It was a good read, and easy to follow, but it still does the opposite of
> what I need to do.  I want multiple small project-specific trees, not a
> myriad of full kernel trees.  Everything else gave me a good starting point
> for doing SCM-controlled kernel development using BK.  Thanks for the
> pointer.

So use hardlinked clones.  See the clone -l, and the relink docs.  You'll
burn 87MB for the baseline and then 1240 inodes for the directories in
each hardlinked clone.  If inodes take 4K each, that's 5MB, which isn't
free, but that's the best we can.  We'll cut that in half when we get
rid of the SCCS directories.

If you wanted to complain that BK doesn't restore the hardlinks after a
file is updated in multiple clones, that's a legit complaint.  You can
solve that with a post-incoming trigger which runs relink, but it would
be nicer if there was a way to make BK do that automagically.

> for me it boils down to using the best tool for the job.

Hey, I'm all for that.  If Arch worked better for Linus and the
maintainers, I'd be the first to urge them to switch.  We aren't getting
financial benefit from the kernel use of BK, which is a bummer, but that
is OK, that wasn't the point.  The point was to reduce the workload on
the critical people in the equation and that's what we focussed on.

I'm not at all convinced that you have explored BK enough to know whether
it will help you or not, and I'd appreciate it if you did so rather than
claiming it doesn't work.  All you are saying is that it doesn't work
exactly how you work now.  That may or may not be the same as saying it
can't help you (or others).  You won't know until you go explore.

Both Linus and I were fairly convinced that the BK take-it-all whether
you want it or not model was a showstopper.  Then Garzik figured out
a way around that which works well enough for now.  A lot of useful
work is happening faster because of what he figured out.  My complaint
with you is that you are assuming that you can't make BK work faster
for you without trying it or thinking about it.  Does BK mimic your
working model?  No.  Does that mean it can't help you?  Not clear.
That's the point.

I think BK can help you and you are so stuck on one way of doing things
that you are ignoring that possibility.  That's OK with me so long as
it is just you, but you're posting in a public forum, to a group of
people that I'm trying to help, and as long as you do, I'll be here,
annoying as heck, explaining why you are wrong.  I'm not saying that you
are wrong about BK drop-ins, you're right about that.  We're fixing it as
fast as we can, it's in my top 3 work items right now.  In the meantime,
if you poked around, there are lots of ways to use BK and I'm 99% sure
you could find one that would result in less work overall for you than
what you are doing now.  I don't care if *you* find one, I care if 
others find one.  We're trying to maximize productive work for the
largest number of people, and I find your posts counterproductive to
that goal.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [Linux-fbdev-devel] Fbdev Bitkeeper repository

[James S. <jsi...@tr...>]

Oh my!!!! 

    To answer the question are we going to drop CVS drop in support of the
linux console project. No!! The reasons have nothing to do with politics
or who is better. The reason for this is some people want to use CVS and
don't want to spend the time learning bitkeeper. That is their choose. I
don't want to force anyone to do something they don't want. Have both
bitkeeper and CVS is a plus in many ways to many people. 
  
P.S 
    I'm just learning bitkeeper so if it is possible to do a drop in
techique with bitkeeper I would be happy to learn how to do it.

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

Re: [Linux-fbdev-devel] Fbdev Bitkeeper repository

[M. R. B. <mr...@0x...>]

* Larry McVoy <lm...@bi...> on Tue, Apr 16, 2002:

> On Wed, Apr 17, 2002 at 12:04:12AM -0500, M. R. Brown wrote:
> > Not sure I follow here, you're a bit vague about "doing the same thing".
> > Do you mean syncing from the mainline kernel? =20
>=20
> Syncing from the main kernel, synching from someone else, syncing with=20
> a coworker, whatever.  It doesn't really matter.  With the limitation=20
> that BK wants you to eat everything that the other guy has that you don't,
> it all just works.  And you can sync from N different places all of which
> happened to have the same patch in the same changeset, and it gets applied
> once, BK knows it has it already.
>=20
> BK isn't perfect, but you are looking at it through CVS colored glasses.
> Take 'em off, it's got some stuff that will save you time and effort.
>=20

That's cool.  That's what should be in a SCM.  I guess we may have a
misunderstanding where I say "drop-in tree" and you assume I mean using CVS
to tag and branch a subset of the kernel source?  The drop-in tree is what I
described in my initial response to you so many posts ago.  It doesn't have
to be specifically tied to a CVS-centric mode of development, but before so=
me
of the other SCMs came into fruition, CVS was the easiest (or most popular
if you insist it wasn't easy) way to do it.  Now we have advanced SCMs
available, and I hope to use one that will still support drop-in trees
while allowing me access to all the whizbang features that will make my
life easier.

> > For the LinuxSH project, we moved from tracking the full kernel tree (v=
ia
> > CVS) to a drop-in tree structure mainly because of the difficulty in
> > tracking all upstream kernel changes at once.  It wasn't really related=
 to
> > what CVS did or did not offer.
>=20
> Disagree.  CVS sucks at tracking an external source of change while
> maintaining your own changes at the same time, in the same tree.
> It really sucks at that, you are forced into a broken branching model
> with awful merge characteristics.  Try the same thing with BK, it's
> a lot nicer, most stuff just automerges, and the stuff that doesn't
> only needs to be merged once.  Your claim that it isn't about CVS
> doesn't make much sense when CVS forces you to split your subtree
> out.  Having an _option_ to do that is one thing, being forced to
> do it is another.
>=20

I'd hate to sound like I'm trolling or being a broken record.  But I don't
currently have that option with BK.  This is the option I want, to be able
to not have to worry about pulling all changes or being able to cordon off
only the bit I want/need to work with.  See the above as to why CVS isn't
just the means, it's just the tool currently used for drop-in maintenance.
Give me proper drop-in support using BK (or any other modern SCM tool), and
I'm sold.

> > I never said anything about working in isolation in any of my posts.  A
> > drop-in tree is only usable when "dropped in" or symlinked on top of a =
full
> > kernel tree. =20
>=20
> And if that tree has changes in the files that you are "dropping in"?
> You just stomped on them.  Or you are left with an even more broken
> merge model than CVS.  And what about file renames.
>=20

When my drop-in tree file changes upstream, I'll find out in the next
upstream sync.  Obviously if my drop-in tree is current, that file hasn't
changed yet.  File renames are broken, but I never pretended they weren't. =
 I
guess what you're saying is it comes down to me weighing out feature-rich
set vs. feature-less set, where BK is the former, and I should expect to ha=
ve
to sacrifice my entire development model (drop-in trees, not CVS) for the
bloated model that BK currently *enforces* (see your above paragraph about
having the option).

> > Also, the size of a drop-in tree is a side effect of its composition, it
> > was used to illustrate the benefit of the simplicity of drop-in trees -=
 if
> > you recall the introductory paragraph of my original reply to yours, I =
said
> > that drop-in trees are most useful for kernel subsystems and backend
> > (architecture) ports. =20
>=20
> Agreed.  We're headed towards breaking up the kernel tree into
> subrepositories for that reason.
>=20

This was already being done with the satellite projects and drop-in
trees, but didn't have the benefit of being SCM-controlled *globally*.  I'd
very much like to see this happen.  Was there any timeframe on this or
should I just start searching lkml archives?

>=20
> > So, splitting trees in BK.  Do you mean by using native BK commands, or=
 by
> > planning ahead and using multiple repositories?  Perhaps when you've
> > finished flaming me and defaming CVS you can give me a valid response a=
s to
> > how one would maintain a drop-in tree using BK. =20
>=20
> Perhaps when you have finished flaming me, you can go use the tool, read
> the docs, and learn what it can do.  Part of the problem I have is that
> you are, in a public forum, saying that BK is this and that, based on your
> perceptions from 2 years ago when you said you used it on the ppc tree.
> I can't imagine that you used it very much, because there is not a
> single changeset in the tree with your login on it.  So maybe you are
> making your comments based on a 2 year old reading of the docs, rather
> than actually using it.  That is pretty annoying and a waste of time.
> Go learn the tool, if you want an education, then buy some training.
>=20

Nope, I said that based on what I read at www.bitkeeper.com, BK didn't
support drop-in trees *today*.  I said that the last time I actively used
the tool was 2 years ago, but I haven't had a reason to use it since then.
In a public forum, which you use to promote sales and use of your product, I
stated quite simply and plainly that BK won't allow me to do drop-in trees,
with the simplicity of CVS.  Even using a full kernel source tree as CVS
HEAD and branching subsets of HEAD into small drop-in like branches does
what I need to do in CVS.  This is even before you start worrying about
automerging and file renaming - I can't do the above using BK - for kernel
development.

Two years ago, or today, BK still doesn't do it, not without requiring
massive structural changes to the master repository by the project owner -
not the satellite maintainers.  This requires a significant amount of
planning ahead and effort from Linus (or whoever ends up doing it), where
using the drop-in tree model that burden is placed on the satellite
maintainer.  When I decide to start and maintain the "linux toaster
driver", I pull out the source I need from mainline, and setup my drop-in
tree from that and my new imports.  The BK way to do it is to simply "clone
the master" and work from that.  Not a drop-in.

I voiced a legitimate concern about why drop-in trees were useful, and why
I wouldn't be able to contiue their development using BK.  You proceeded (f=
or
a couple of posts at least) to dodge that concern with arguments of why CVS
pales in comparison to BK.  That I didn't really care about, and maybe you
should be asking yourself, "If I didn't have the correct answer and I can't
accurately address this guy's concern, why did I bother replying in the fir=
st
place?"

> As for splitting trees, "bk help csetprune".  It not only splits trees,
> it maintains the repository changeset history graph, no small feat.
> But it's a 1-way, 1-time operation, you can't unsplit.  So it's something
> that I suspect will happen when Linus wants it.
>=20
> And you could find this information by
>=20

Right.  We can't do it, only the repository owner can.  By your own
admission the drop-in tree as I described it isn't supported:

"Ahh, OK, we're already working on this.  We call 'em nested repositories
and one of the problems they solve is exactly the problem you described.
Think of them as CVS modules, with a little more formality, and you're
about there.  They also solve a bunch of performance problems."

The "csetprune" command you've pointed me to apparently doesn't do this.

> > You seem to be stuck on "why CVS sucks" while I'm trying to convey "why=
 CVS
> > does what I need it to do" as far as drop-in trees are concerned. =20
>=20
> Except it *doesn't* do what you need it to do.  You proceeded to hand
> wave over the many places where CVS won't work.  You haven't addressed
> either of the two big problems, renames and content changes in the
> upstream tree.  In the 2 months of usage, Linus' tree has seen 1289
> renames, of which 767 where real renames, not deletes.  How does your
> drop in model handle those?  What about content changes that you don't
> have yet, how does it handle that?  In both cases, the answer is "it
> doesn't".  So you are doing work that you don't need to do, by hand.
> That seems misguided when there is a tool that will do that work for
> you.
>=20

Yep, you're correct, except about the handwaving part.  Last I checked, 2.2
was still being maintained, and 2.4 is also being maintained.  Believe it or
not, I have to be bothered with tracking changes between all of these
versions *and* 2.5, and at least the 2.2 variant still needs to be done by
hand.  2.4 and 2.5 are now SCM-controlled by BK.  That's great, and I'm
being serious here.  But it can't cope with the drop-in style, and at this
point I can't be coerced into a new mode of development.  If BK could sanely
handle drop-in trees (the right way), trust me, I'd already be using it.  B=
ut
I'm still forced to do the merging work by hand, if I insist on maintaining
the drop-in tree (without CVS), even if using a BK clone as my source base.

My tool needs to do what I tell it to, not the other way around.

> > conditioned to attack (or belittle) anyone that doesn't accept BK as
> > gospel.  I understand taking pride in your work, but damn!  Take it eas=
y.
>=20
> It's got nothing to do with gospel, it's got everything to do with you
> making claims based on no work on your part, not even recent usage.
> BK isn't anywhere near Linus' definition of the best (i.e., it can't
> get better).  Nowhere near.  But it's quite useful if you figure out
> how to use it.  And we're making better as fast as we can.
>=20

If you were able to propose a sane way to continue using the drop-in model
using BK, then I'd have no problems taking you seriously.  My only claim
was that BK couldn't handle drop-in trees.  I didn't say it sucked overall
as a SCM or that I wanted to protest because it wasn't open.  The "work" was
me perusing the bitkeeper webpage, and going back and forth with you, the g=
uy
I thought would be the most intelligent on all of BK's features.  Are you
saying the only way for me to evaluate a tool (one that I haven't used in
ages) is to use it?  I can't rely on documentation or peer reviews and
comments?  Wouldn't my time be spared if you just told me what it would or
wouldn't support?

> Contrast your comments / homework with Jeff Garzik, just for fun.  BK
> has some limitations he didn't like, so he asked a few polite questions,
> figured out how to work around the limitations, and wrote it up in a
> doc (have you read it?).  His approach has been widely adopted, there
> are at last count around 130 slightly different BK trees sitting on
> bkbits.net. =20
>=20

This?

http://www.uwsg.iu.edu/hypermail/linux/kernel/0202.2/1060.html

It was a good read, and easy to follow, but it still does the opposite of
what I need to do.  I want multiple small project-specific trees, not a
myriad of full kernel trees.  Everything else gave me a good starting point
for doing SCM-controlled kernel development using BK.  Thanks for the
pointer.

> In summary, because I've had enough of this thread, your drop in tree
> is a hack, it doesn't handle even the basics of SCM, and you haven't
> shown how to handle those.  BK has plenty of problems, but it least it
> handles the basics.  What you are doing is like working in a file system
> which makes you edit the raw disk to do renames and/or content merges.

Point taken about the drop-in tree being a hack, when used within the
limitations of CVS.  With a SCM that could do it intelligently, it would be
overly useful, but unfortunately BK can't do it at all (or, it does it in
the complete reverse).

I already have been looking at alternatives to CVS that would allow me to
maintain a master kernel source repository with many satellite "branches" t=
hat
would be equivalent to small drop-in trees for the various kernel ports and
subsystems.  I would also need a reasonable way to do merges between the
satellites and the trunk, and being able to do it locally with cloning would
be a major plus.

I've found that Arch comes the closest to what I need, so I've been "doing
my homework" with it.  When I do run into snags, or when Arch trips over
itself when I'm trying to maintain my satellites at least I do have the sou=
rce
instead of the requirement that I bitch to you about missing functionality.=
  I
suppose for the project I'm working on, once it gets to the point where I
need to grab up to the minute changes, I can be bothered with setting up
either an Arch<->BK gateway or find another means to migrate updates from
the latter.

If BK can gain (intelligent, where satellite maintainers can split, not
just root) drop-in support to where it doesn't make sense for me to use
Arch for Linux kernel projects, I'd start using it (and recommend it) for my
satellite projects immediately.  Again, for me it boils down to using the
best tool for the job.

M. R.

Re: evdev types

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

On Wed, Apr 17, 2002 at 09:56:05PM +1000, Brad Hards wrote:
> On Wed, 17 Apr 2002 18:21, Vojtech Pavlik wrote:
> <snip>
> > Not really a 2d bitfield, more like a bunch of 1d bitfields with uneven
> > lengths. You pass an argument selecting which one you want and you get
> > it. I think EVIOCGBIT is quite OK, because it doesn't really depend on
> > the data type ... it just copies a chunk of memory.
> >
> > What is probably the only wrong w/ the bit arrays is the way they're
> > passed through by /proc and hotplug support. And that can be fixed
> > without any major pain, because noone is using that on 64-bit systems
> > yet.
> OK, no issue on 2.4, correct?
> This was stuff you added in 2.5?
> 
> ><snip>
> > 	ioctl(fd, EVIOCGBIT(EV_KEY, sizeof(my_buffer)), buffer);
> Ah, I think I have it now. For 
> 
> ioctl(a, EVIOCGBIT(b, c), d)
> 
> a is the file descriptor for the event device you want
> 
> b is the type of descriptor bitfield to return
> 	0 for the type of descriptors that are used
> 	EV_KEY for the key bitfield
> 	EV_REL for the relative axes bitfield
> 	EV_ABS for the absolute axes bitfield
> 	EV_MSC for the miscellaneous bitfield (not used yet?)
> 	EV_LED for the bright lights bitfield
> 	EV_SND for the loud noises bitfield
> 	EV_REP for the repeat function bitfield (not used yet?)
> 	EV_FF for the force feedback bitfield
> 
> c is the maximum number of bits to return
> 	If the number of bits available is greater, then you get a warning message

Bytes.

> d is a pointer to the memory to put the bitfield

Yes.

> and the return value is the number of bits transfered (if it succeeds) or 
> -EFAULT if it fails. 

Bytes, again.

> The number of bits transferred is the lesser of c, and 
> the number of bits for that descriptor type (eg forb == 0, it is EV_MAX,  b 
> == EV_KEY, it is KEY_MAX; for b == EV_REL it is REL_MAX, and so on).
> 
> OK, my only question now is "how do you get the descriptor bitfield for 
> EV_RST?"

There is none. There are no bits for EV_RST, it's only one event in its
own class.

-- 
Vojtech Pavlik
SuSE Labs

Re: [Linux-fbdev-devel] Fbdev Bitkeeper repository

[Roman Z. <zi...@li...>]

Hi,

On Tue, 16 Apr 2002, Larry McVoy wrote:

> [bk commercials removed]

Am I the only who wished hearing you say only once "Hey, this offtopic
here, let's move the discussion to the right ml."?

bye, Roman