linuxconsole-dev

Re: evdev types

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

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

d is a pointer to the memory to put the bitfield

and the return value is the number of bits transfered (if it succeeds) or 
-EFAULT if it fails. 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?"

Brad

Re: evdev types

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

On Wed, Apr 17, 2002 at 11:58:31AM +1000, Brad Hards wrote:
> On Mon, 15 Apr 2002 22:14, Vojtech Pavlik wrote:
> > On Mon, Apr 15, 2002 at 08:41:33PM +1000, Brad Hards wrote:
> > > On Mon, 15 Apr 2002 17:40, Vojtech Pavlik wrote:
> > > > Yes, if this is cleaner. I have much bigger worries about the size of
> > > > 'long' in EVIOCGBIT and /proc/bus/input/devices output on archs that
> > > > support mixed 32/64-bit binaries (SPARC, PPC, x86-64).
> > >
> > > Oh. Ugly.
> >
> > Yeah. setbit() et al work on longs, and longs are OK in an API which
> > isn't on a mixed 32/64-bit arch. But since the 32/64 bit stuff happens,
> > it gets pretty ugly.
> OK, I have looked at it some more, and it is scaring me quite a bit :)
> 
> The approximate plan is to return a 32 bit quantity (uint32_t or __u32, 
> depending on whether Greg convinces me or not).
> 
> I am not sure I really understand what EVIOCGBIT is doing. It looks like it 
> returns a 2-d bitfield array, where one dimension is the event type, and the 
> other dimension is a index of possible options within that event type. The 
> "zeroth" option is whether that event type is supported at all by the device.

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.

> The result can be constrained by arguments so
> ioctl(fd, EVIOCGBIT[EV_KEY,EV_KEY], result[0])
> will only return the options for keys, as a bitfield array.

I think that'd be

	ioctl(fd, EVIOCGBIT(EV_KEY, sizeof(my_buffer)), buffer);

> 
> Is this all basically true?
> 
> What is EV_RST?

An RESET event. It's sent to reset the device or received when the
device was reset. Currently unused, but planned for use with possible
recalibration (after changing the EVIOCGABS boundaries) of touchscreen and
joystick devices.

> Is the limit on KEY_MAX (in evtest.c) showing that there will probably always 
> be more KEY options that RELative or ABSolute options?

Yes. There is more different key types than joystick or mouse axis
types.

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

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 :)

Patch against 2.4.19-pre7 and evtest are enclosed.

How does this look?

Brad

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

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

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?  

Syncing from the main kernel, synching from someone else, syncing with 
a coworker, whatever.  It doesn't really matter.  With the limitation 
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.

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.

> 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 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.  

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.

> 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.  

Agreed.  We're headed towards breaking up the kernel tree into
subrepositories for that reason.

> However, I do mind how much of my broadband bandwidth is used
> (since I'm stuck with a flaky ADSL link) and I'm sure developers still on 56K
> links also mind.

BK's pretty stingy with bandwidth.  I think the openlogging tree has
some problems, but other than that, BK uses very little bandwidth, far
less than CVS.  It knows what needs to be transfered, CVS has to look,
over your net connection.  We have lots of people tracking the kernel
trees via a modem.  You can play games to save more bandwidth too,
if you know you have a common gca in a local tree, and you want to get
a local copy of some other "branch", clone -r back to the gca and then
pull from the branch into the new repository.  You'll save transfering
all the stuff that you already had.

> 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 as to
> how one would maintain a drop-in tree using BK.  

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.

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.

And you could find this information by

	http://www.bitkeeper.com
	click on search
	type in "split"
	hit return,
	it's the 3rd item down.

> 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.  

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.

> conditioned to attack (or belittle) anyone that doesn't accept BK as
> gospel.  I understand taking pride in your work, but damn!  Take it easy.

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.

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.  

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.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

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

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

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

>=20
> > This requires consistency on the part of the drop-in tree maintainer, to
> > sync to and from the mainline kernel.  Usually, only the maintainer sen=
ds
> > patches upstream, but experienced project developers can easily merge
> > changes coming from the mainline kernel.  I'm not aware of how BK may
> > automate this or make it easier, but this is one of those "use rigid
> > guidelines where CVS falls short" situations.  *Shrug*, a bit of extra
> > work, but still easier than tracking an entire tree's worth of changes.
>=20
> That's not a widely shared opinion.  Check with the people maintaining=20
> their own trees, tracking the mainline and/or some branch.  Saying
> "CVS falls short" is quite the understatement.  Try doing the same=20
> thing with CVS (or whatever else) and you'll see what I mean.  CVS
> is great for simple things; the kernel isn't simple.
>=20

Not sure I follow here, you're a bit vague about "doing the same thing".
Do you mean syncing from the mainline kernel?  It's easier to sync from
Linus because BK is being used to do it (e.g. because the Linus kernel is
tracked by BK?)?

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.

> There is a basic flaw in your reasoning.  You're assuming that you
> can do all your work in isolation.  That's not true, the rest of the
> tree is changing around you and you need to build/test against that.
> Not doing so is just cutting corners and while I'm sure you are smart
> enough not to get burned too often by this, I'm equally sure you have
> and will get burned by it again.  Noone is immune.  And all of this is
> to save some disk space?  Disk drives are about $1/GB on pricewatch.
> A kernel tree, compressed, takes less than .1GB.  So you saved yourself
> 10 whole cents.  Wheeeeeee!
>

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.  Because it's not a complete tree, it won't build otherwise.
In order to build and test a drop-in tree, you must have the current
mainline kernel version to drop against (whatever kernel version that has
been specified in the drop-in tree).  If something breaks upstream
(which happens more often than not, esp. in architecture ports), then
you'll see it as soon your build fails or when your kernel panics.  It's
impossible to develop a drop-in tree in complete isolation, so I'm not sure
why you thought this was possible?

Say cache handling is modified kernel-wide and it breaks a number of
architecture backends (this is a real world example, somewhere around
2.4.10 or so this actually happened).  Until you work out a fix for say,
the SuperH architecture, you pull in and modify the global cache-handling
files and modify it locally.  Once a proper fix has been developed, you
send your arch-specific cache routines upstream and remove the global
cache-handling files from your drop-in tree.

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.  The number of files that are specific to these
projects are a fraction of the size of the full kernel, and because of
this, it gives you a simpler, more readable view of your "corner" of the
kernel.  I don't know why you assumed I was on some fanatical quest to save
disk space.  However, I do mind how much of my broadband bandwidth is used
(since I'm stuck with a flaky ADSL link) and I'm sure developers still on 5=
6K
links also mind.

[snip]
>=20
> > Right, but CVS-like operations in BK currently won't allow me to do dro=
p-in
> > trees.  It's not so much a complexity of use issue as it's an issue of =
how
> > things are implemented or done in CVS vs. BK.  Because of its simplistic
> > view of repositories and how to work with them, CVS wins with small, fi=
nely
> > cultivated (excuse the lack of a better term) trees, whereas BK's compl=
ex
> > view of repositories does not.
>=20
> Nonsense.  You can do drops right now.  Just split the tree apart and
> clone the parts you need.  All the nested repos are going to do is=20
> give you some syntatic sugar which allows you to do just that.
>=20

Cool, finally you give a straight answer to an honest query.  You orignally
asked why I thought BK was inefficient as opposed to CVS, so I assume you
misunderstood my response to James.  I'm operating on the available info I
have on BK, where cloning is an all or nothing operation.  Is this not the
case?  Can you selectively pull in parts of the tree (similiar to drop-in
functionality) and is anyone doing it?  This is why I was opposed to the
linuxconsole drop-in tree moving to BK, not because of "some other agenda"
but because it screws up how I develop and test the tree.  I guess in
retrospect, you really didn't have a valid entrance into the thread, but I
guess any post including "Bitkeeper" catches your eye?

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 as to
how one would maintain a drop-in tree using BK.  The isolation argument
doesn't fly since drop-in trees are far from isolated, and the disk space
thing was taken a bit out of context, but that's understandable.

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.  From
every other pro-BK anti-everyother-RCS post I've read from you, you seem
conditioned to attack (or belittle) anyone that doesn't accept BK as
gospel.  I understand taking pride in your work, but damn!  Take it easy.
If you really wanted to help me (or convert me) to using BK, you'd just
tell me how the heck to do a drop-in tree, and I'd walk away enlightened.

[snide personal insults snipped]
>=20
> At the same time, it would also be great if you left off describing tools
> you don't use.  I don't know what part of the kernel you work on, but
> I can assure you that I won't go complaining about it unless I actually
> use it and think about it first.
>=20

I was able to ascertain that BK didn't support drop-in trees by just
reading www.bitmover.com.  Was there somewhere else I should've been
instead?

M. R.

Re: Console Support for event devices.

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

> > For that other 5-10%, the event device provides all the information you would
> > need to do mouse, keyboard, etc.  However you will get ALL events destined for
> > ALL consoles/terminals/etc, regardless of whether it was intended for you or vc
> > 6 or the X-server or some x-term ... etc.
> 
> xterm? Uh-huh, how? xterms get mouse/keyboard data via the X protocol.
> 
> Actually a much more interesting project would be to write a console as
> an userspace program connecting to /dev/pty's and using input and
> framebuffers to implement all that's expected from a console. Including
> nifty stuff like complete Unicode support, etc.

Consoled deamon. This would also be useful for people who like weird
comobs like 5 displays and 3 keyboards. As for linking the input api to a
specific console bad. Consider for PDAs the only tty would be a serial
TTY/console. Yet you still would have a input device and a framebuffer.
It would be difficult to relate a input or bunch of input devices to a
serial TTY. 

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

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

On Tue, Apr 16, 2002 at 09:41:49PM -0500, M. R. Brown wrote:
> * Larry McVoy <lm...@bi...> on Tue, Apr 16, 2002:
> > Ahh, OK, we're already working on this.  We call 'em nested repositories
> 
> That's good to hear, and interesting as well.  Any particular reason why
> this wasn't implemented until now?  Did you not see a high demand for
> satellite projects, or was it just assumed that you'd only ever need the
> clone method of development?

BK supports gzipped repositories and hard linked repositories, so a
compressed tree takes about 87MB (when the checked out tree is 169MB),
and a hard linked tree takes effectively no space at all.  So making
subsets had very little benefit and removed a significant advantage:
with BK when you say "as of such and such a changeset", there is no
ambiguity as to what you mean, it implies the whole tree.  There is no
chance of doing that with a subset tree.  Small gain in disk space,
big loss in reproduceablilty.  Seems like a bad tradeoff.

> This requires consistency on the part of the drop-in tree maintainer, to
> sync to and from the mainline kernel.  Usually, only the maintainer sends
> patches upstream, but experienced project developers can easily merge
> changes coming from the mainline kernel.  I'm not aware of how BK may
> automate this or make it easier, but this is one of those "use rigid
> guidelines where CVS falls short" situations.  *Shrug*, a bit of extra
> work, but still easier than tracking an entire tree's worth of changes.

That's not a widely shared opinion.  Check with the people maintaining 
their own trees, tracking the mainline and/or some branch.  Saying
"CVS falls short" is quite the understatement.  Try doing the same 
thing with CVS (or whatever else) and you'll see what I mean.  CVS
is great for simple things; the kernel isn't simple.

There is a basic flaw in your reasoning.  You're assuming that you
can do all your work in isolation.  That's not true, the rest of the
tree is changing around you and you need to build/test against that.
Not doing so is just cutting corners and while I'm sure you are smart
enough not to get burned too often by this, I'm equally sure you have
and will get burned by it again.  Noone is immune.  And all of this is
to save some disk space?  Disk drives are about $1/GB on pricewatch.
A kernel tree, compressed, takes less than .1GB.  So you saved yourself
10 whole cents.  Wheeeeeee!

Suppose you are a paid developer.  Around here, a kernel hack gets about
$100K/year, and actually costs a company about $180K/year.  OK, let's say
you live someplace really cheap so it is 1/4th that.  So that's $22.5
an hour.  Or 37.5 cents a minute.  So if you waste 20 seconds because
you saved yourself 100MB of space, you blew it.  It doesn't make sense.

> I meant as far as styles of development.  Yes, CVS can cause some headaches
> if used improperly, and some shortcomings are either excused or hacked
> over.  However for small projects or projects with a group of close-knit
> developers BK is considerably more complex to setup and use.  A lot of the
> "problems" that BK solves are either not required for smaller projects or
> are second nature to those experienced in using CVS.
> 
> Yes, I see the immediate benefits of being able to clone a repository and
> do local development, pulling in updates or pushing changes mainstream
> where appropiate.  Fortunately, I have Arch to study for this, which I have
> to say I'm much more comfortable working with.  Yes, I've used BK in the
> past (for the PPC tree), but it's been about 2 years so maybe it's improved
> since then?

So you are looking at a 2 year old view of a a tool which has existed
for 4 years.  Yes, of course it has improved, it has improved a lot.
How about you go use it and then make your comments?  Come on, get a clue.
Judging anything which is moving that fast by a 2 year old snapshot is
obviously wrong.

A sane person might conclude you have some other agenda.

> Right, but CVS-like operations in BK currently won't allow me to do drop-in
> trees.  It's not so much a complexity of use issue as it's an issue of how
> things are implemented or done in CVS vs. BK.  Because of its simplistic
> view of repositories and how to work with them, CVS wins with small, finely
> cultivated (excuse the lack of a better term) trees, whereas BK's complex
> view of repositories does not.

Nonsense.  You can do drops right now.  Just split the tree apart and
clone the parts you need.  All the nested repos are going to do is 
give you some syntatic sugar which allows you to do just that.

Note that I'm not suggesting that you personally do that, it's becoming
apparent to me that you either have an ax to grind or you are just plain
lazy, and either way I'd love for you to keep using CVS, that would be
great.  

At the same time, it would also be great if you left off describing tools
you don't use.  I don't know what part of the kernel you work on, but
I can assure you that I won't go complaining about it unless I actually
use it and think about it first.

> One of the listed BK features is being able to collaborate with other folks
> who've cloned a repository - are the backend/subsystem maintainers even
> doing this?  Is there any collaboration going on between say, the Linux/ARM
> and USB BK repositories?  

There is certainly some of that, look at the histories to see the merges.
I think Linus does most of those but I see merges originated by others
in their private trees all the time, look at the openlogging tree.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

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

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

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

> >=20
> > A drop-in tree (also called "shadow trees" by Keith Owens of kbuild), i=
s a
> > small set of files intended to be applied against a larger parent body =
of
> > code.  For example, a kernel subsystem or backend project (linuxconsole,
> > LinuxSH, Linux-MIPS) will only maintain the minimal number of files that
> > are specific to that backend, e.g. include/asm-mips/, arch/mips,
> > /arch/mips64, etc. for any files local to the project. =20
>=20
> 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.
>=20

That's good to hear, and interesting as well.  Any particular reason why
this wasn't implemented until now?  Did you not see a high demand for
satellite projects, or was it just assumed that you'd only ever need the
clone method of development?

> I tend to agree with your comments about not wanting the whole tree, to
> some extent.  You are aware, of course, that your drop in may not work
> if the rest of the tree has moved on.  So the drop in has a limited
> life span in isolation.  With that caveat, drop ins are nice and we'll
> have them before too long.  Unlike CVS, we like to be able to reproduce
> the tree accurately so there is more work to do.
>=20

This requires consistency on the part of the drop-in tree maintainer, to
sync to and from the mainline kernel.  Usually, only the maintainer sends
patches upstream, but experienced project developers can easily merge
changes coming from the mainline kernel.  I'm not aware of how BK may
automate this or make it easier, but this is one of those "use rigid
guidelines where CVS falls short" situations.  *Shrug*, a bit of extra
work, but still easier than tracking an entire tree's worth of changes.

> On your comments about CVS being less complex, I don't agree at all.
> Almost all of the BK complexity is to handle problems CVS doesn't
> handle at all.  Another way to say that is when you hit those problems
> BK is much much less complex that CVS.  For example, a simple file
> rename is a nightmare in CVS and a non-issue in BK, it just propogates.
>=20

I meant as far as styles of development.  Yes, CVS can cause some headaches
if used improperly, and some shortcomings are either excused or hacked
over.  However for small projects or projects with a group of close-knit
developers BK is considerably more complex to setup and use.  A lot of the
"problems" that BK solves are either not required for smaller projects or
are second nature to those experienced in using CVS.

Yes, I see the immediate benefits of being able to clone a repository and
do local development, pulling in updates or pushing changes mainstream
where appropiate.  Fortunately, I have Arch to study for this, which I have
to say I'm much more comfortable working with.  Yes, I've used BK in the
past (for the PPC tree), but it's been about 2 years so maybe it's improved
since then?

> If you want to eliminate learning "bk mv foo.c bar.c", just don't do
> that and all of that complexity is never used.
>=20
> I'll be the first to admit that BK is a big system, but it's no more
> complex than CVS if you limit yourself to CVS-like operations.  And=20
> when you go beyond those limits, then BK becomes less complex to the
> user just as CVS is starting to fall over.  Or am I missing something?
> Have you read http://www.bitkeeper.com/cvs2bk.html ?  That covers the
> translation.

Right, but CVS-like operations in BK currently won't allow me to do drop-in
trees.  It's not so much a complexity of use issue as it's an issue of how
things are implemented or done in CVS vs. BK.  Because of its simplistic
view of repositories and how to work with them, CVS wins with small, finely
cultivated (excuse the lack of a better term) trees, whereas BK's complex
view of repositories does not.

I'm not trying to argue as to which is better, I'm just trying to make the
point that I think it's better to use whatever tool is best suited for the
task.  Preaching the benefits of BK over CVS makes no sense when the
desired features aren't there or usuable, so unfortunately your blanket
statements of "BK is a superset of CVS" don't do me any good.  Hopefully th=
is
will filter up to the kernel backend/subsystem maintainers before we see mo=
re
drop-in trees needlessly turning into BK repositories.

One of the listed BK features is being able to collaborate with other folks
who've cloned a repository - are the backend/subsystem maintainers even
doing this?  Is there any collaboration going on between say, the Linux/ARM
and USB BK repositories?  Or is the plan to let things get sorted out when
changes are pushed straight to Linus?  Any maintainers want to comment on t=
he
usefulness (or lack thereof) of BK for maintaining a kernel port (anybody
except Larry)?  Is the fact that syncing with Linus has become
significantly easier the sole reason that BK has become so widespread?

M. R.

Re: evdev types

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

On Mon, 15 Apr 2002 22:14, Vojtech Pavlik wrote:
> On Mon, Apr 15, 2002 at 08:41:33PM +1000, Brad Hards wrote:
> > On Mon, 15 Apr 2002 17:40, Vojtech Pavlik wrote:
> > > Yes, if this is cleaner. I have much bigger worries about the size of
> > > 'long' in EVIOCGBIT and /proc/bus/input/devices output on archs that
> > > support mixed 32/64-bit binaries (SPARC, PPC, x86-64).
> >
> > Oh. Ugly.
>
> Yeah. setbit() et al work on longs, and longs are OK in an API which
> isn't on a mixed 32/64-bit arch. But since the 32/64 bit stuff happens,
> it gets pretty ugly.
OK, I have looked at it some more, and it is scaring me quite a bit :)

The approximate plan is to return a 32 bit quantity (uint32_t or __u32, 
depending on whether Greg convinces me or not).

I am not sure I really understand what EVIOCGBIT is doing. It looks like it 
returns a 2-d bitfield array, where one dimension is the event type, and the 
other dimension is a index of possible options within that event type. The 
"zeroth" option is whether that event type is supported at all by the device.

The result can be constrained by arguments so
ioctl(fd, EVIOCGBIT[EV_KEY,EV_KEY], result[0])
will only return the options for keys, as a bitfield array.

Is this all basically true?

What is EV_RST?

Is the limit on KEY_MAX (in evtest.c) showing that there will probably always 
be more KEY options that RELative or ABSolute options?

Brad

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

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

On Tue, Apr 16, 2002 at 07:08:18PM -0500, M. R. Brown wrote:
> * Larry McVoy <lm...@bi...> on Tue, Apr 16, 2002:
> 
> > > Please tell us that primary framebuffer/input/console development will
> > > continue in the CVS drop-in tree on SourceForge?  Bitkeeper is unable to
> > > support this (easier, more efficient) style of development.
> > 
> > Could you please explain why you think CVS is easier and more efficient?
> > Last I checked, BK was a superset of CVS, but could be used pretty much
> > identically to CVS if that's what you want.
> 
> A drop-in tree (also called "shadow trees" by Keith Owens of kbuild), is a
> small set of files intended to be applied against a larger parent body of
> code.  For example, a kernel subsystem or backend project (linuxconsole,
> LinuxSH, Linux-MIPS) will only maintain the minimal number of files that
> are specific to that backend, e.g. include/asm-mips/, arch/mips,
> /arch/mips64, etc. for any files local to the project.  

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.

I tend to agree with your comments about not wanting the whole tree, to
some extent.  You are aware, of course, that your drop in may not work
if the rest of the tree has moved on.  So the drop in has a limited
life span in isolation.  With that caveat, drop ins are nice and we'll
have them before too long.  Unlike CVS, we like to be able to reproduce
the tree accurately so there is more work to do.

On your comments about CVS being less complex, I don't agree at all.
Almost all of the BK complexity is to handle problems CVS doesn't
handle at all.  Another way to say that is when you hit those problems
BK is much much less complex that CVS.  For example, a simple file
rename is a nightmare in CVS and a non-issue in BK, it just propogates.

If you want to eliminate learning "bk mv foo.c bar.c", just don't do
that and all of that complexity is never used.

I'll be the first to admit that BK is a big system, but it's no more
complex than CVS if you limit yourself to CVS-like operations.  And 
when you go beyond those limits, then BK becomes less complex to the
user just as CVS is starting to fall over.  Or am I missing something?
Have you read http://www.bitkeeper.com/cvs2bk.html ?  That covers the
translation.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

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

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

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

> > Please tell us that primary framebuffer/input/console development will
> > continue in the CVS drop-in tree on SourceForge?  Bitkeeper is unable to
> > support this (easier, more efficient) style of development.
>=20
> Could you please explain why you think CVS is easier and more efficient?
> Last I checked, BK was a superset of CVS, but could be used pretty much
> identically to CVS if that's what you want.

A drop-in tree (also called "shadow trees" by Keith Owens of kbuild), is a
small set of files intended to be applied against a larger parent body of
code.  For example, a kernel subsystem or backend project (linuxconsole,
LinuxSH, Linux-MIPS) will only maintain the minimal number of files that
are specific to that backend, e.g. include/asm-mips/, arch/mips,
/arch/mips64, etc. for any files local to the project.  These could also be
driver files that have architecture-specific changes that haven't been sent
upstream yet.  Because drop-in trees only contain the files that the
project developers care about, they tend to be much smaller and easier to
maintain.  A drop-in tree is usually applied either by copying it over the
stock kernel tree (older method) or by using a simple script that symlinks
the drop-in tree contents (preferred).

I haven't seen a lot of formalization of the basic drop-in tree concepts,
but there are numerous projects that use this style even if they don't
call them drop-in trees, including linux1394.  These types of projects
usually maintain a single directory that is "cp -r"'d on top of the
corresponding directory in the full stock kernel.

=46rom my understanding of Bitkeeper, you can only clone from the master
repository, and you cannot specify a subset of files to work on when doing
so.  Therefore, if you only want to modify the files that pertain to your
backend port, you must first clone the entire Linux tree (or whatever was
imported into the master repository) and then make your local changes.  This
is a bad thing for a couple of reasons.  It becomes a maintainence nightmare
when resolving conflicts with files outside of your project's scope.  If I
maintain the console subsystem, why should I care about the upheaval of SCSI
layer?  Because CVS is simple enough to not require you to clone an entire
repository first, this is never an issue with using drop-in trees.

Secondly, size of the working repository and the size of updates becomes an
issue.  The kernel source sitting on my HD is approximately 151M.  Changes
between -pre versions usually range from 5-10MB.  Am I supposed to waste th=
is
much bandwidth just to clone the master repository and pull updates?

This is why CVS is more suited for this "style" of development.  Purely
technical reasons, not religious.  Now if James is using the drop-in tree
as the import files in the BK repository, versus a full kernel tree, then
that's a different matter.  But I'm really not interested in complex BK
commands that will somewhat allow the development of drop-in trees (if such
commands even exist).  It may seem silly to you, but I prefer KISS methods
of development and CVS is just fine for what we're trying to do in the
kernel backends.  BK is overkill and an impedement.

Granted a lot of the responsibilty of submitting patches and sync'ing falls
on the maintainers shoulders, so perhaps my argument falls on deaf ears
where they are concerned (as they are more concerned with keeping up with
Linus than with project developers such as myself).

[Note I didn't go into any detail about how drop-in trees are tagged
and sync'd against the stock kernels...]

M. R.

Re: Place of the iforce driver

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

On Wed, 17 Apr 2002 06:31, Johann Deneux wrote:
> Hi,
>
> I saw that James moved the hid code to drivers/usb/input. Shouldn't the
> iforce code go there as well ?
The USB project just went through a major re-organisation. There should be a 
README in the driver/usb directory (although it didn't appear to make it to 
the CVS, and I haven't actually checked the source distro) that explains 
where things live under drivers/usb.

> It's not really clear to me, as it works with USB or RS232.
The only technical reason (that I can see, I'm not very familiar with 
linuxconsole yet) is if you need to bind to underlying USB code when 
everything is built into the kernel. USB init runs very late, and you really 
want to make sure that everything is ready to go. 

Brad

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

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

> Please tell us that primary framebuffer/input/console development will
> continue in the CVS drop-in tree on SourceForge?  Bitkeeper is unable to
> support this (easier, more efficient) style of development.

Could you please explain why you think CVS is easier and more efficient?
Last I checked, BK was a superset of CVS, but could be used pretty much
identically to CVS if that's what you want.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

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

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

* James Simmons <jsi...@tr...> on Tue, Apr 16, 2002:

>=20
> Hi folks!!
>=20
>   Just to let you know I created a bitkeeper repository for the
> framebuffer layer. Anyone wanting to add stuff please send me a key
> generated by ssh-keygen. Thanks.=20
>=20

Please tell us that primary framebuffer/input/console development will
continue in the CVS drop-in tree on SourceForge?  Bitkeeper is unable to
support this (easier, more efficient) style of development.

M. R.

Fbdev Bitkeeper repository

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

Hi folks!!

  Just to let you know I created a bitkeeper repository for the
framebuffer layer. Anyone wanting to add stuff please send me a key
generated by ssh-keygen. Thanks. 

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

Place of the iforce driver

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

Hi,

I saw that James moved the hid code to drivers/usb/input. Shouldn't the 
iforce code go there as well ?
It's not really clear to me, as it works with USB or RS232.

-- 
Johann Deneux

Synced to 2.5.8

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

As you can see I synced up to 2.5.8. Have fun!!!


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

Re: sidewinder driver

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

Would you like me to add to CVS? 

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

On 16 Apr 2002, Fabien Brachere wrote:

> I improve the driver of the Sidewinder force feedback: you can now
> upload a constant or periodic effect and play it.
> I add an utility to test it (it's a modified fftest of J. Denneux).
> You can download those things in http://madfab.free.fr/ff/
> 
> Fabien Brachere
> 
> 
> 
> 
> 
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> 

Re: Console Support for event devices.

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

> So, if programs wanted to use /dev/input/eventX for input instead of stdin, 
> they would get ALL of the events that the input device generates regardless 
> of who has the device focus. 

You are talking about a topology problem. The best way to handle this to
to create a group for each different desktop. Then assign a device to one
of these groups. This is also a issue for alot of things. Take sound cards
for example. It is a matter of permission handling tho. 

> BTW, is there a "release date" for 2.6.0 rumored, talked about, scheduled,
> anything?

Nope. Very far away. 

Re: Paper

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

> >    I just placed in CVS a html version of a paper I plan to present at a
> > talk in Ottowa soon. Have a look at:
> >
> > http://linuxconsole.sf.net/paper
> >
> > Yes lots is missing, I just started. I'm leaving the input section to you
> > Vojtech to fill in.
> I gave a paper at linux.conf.au in February, which has some stuff on the input 
> layer with USB (since that is most people's experience with USB). You might 
> be able to use some of the text or diagrams. See:
> http://www.linux-usb.org/linux.conf.au.02/
> for original KOffice formats and HTML renderings.

Thank you. It looks great. 

Another ruby against 2.4.18

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

http://startx.yo.lv/b-ruby-2.4.18-20020411.bz2
Only x86 arch here!

Hi

Bugs:

Sometimes kernel oops in drivers/char/tty_io.c init_dev().
This will randomly repeat if You start and stop XFree more times.
After make clean will  die-out (may be not).

oops in   drivers/char/keyboard.c
function kbd_keycode()  damned (!L_ECHO(tty) &&
tty->driver.chars_in_buffer(tty))
You shold more times press Alt and LeftArrow, RightArrow.

These both I couldn't find and patch.

All framebuffer stuff removed - hard for me.

Splinter off 2002-03-11


Aivils Stoss

sidewinder driver

[Fabien B. <fab...@fr...>]

I improve the driver of the Sidewinder force feedback: you can now
upload a constant or periodic effect and play it.
I add an utility to test it (it's a modified fftest of J. Denneux).
You can download those things in http://madfab.free.fr/ff/

Fabien Brachere

Re: evdev types

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

On Mon, Apr 15, 2002 at 11:11:33PM +1000, Brad Hards wrote:
> On Mon, 15 Apr 2002 20:22, Brad Hards wrote:
> > On Mon, 15 Apr 2002 17:40, Vojtech Pavlik wrote:
> > <snip>
> >
> > > Feel free to submit a patch. :) I'll most likely accept it.
> >
> > OK. I'll attack this problem in small chunks.
> >
> > Patch against evtest.c and patch against 2.4.19-pre6 attached, just
> > attacking the EVIOCGID ioctl at this stage. Note that most of the kernel
> > changes are in driver/usb.

> Note: I missed a bit in the patch - should have incremented the version 
> (EV_VERSION). Please don't forward the patch without adding that part.

May I suggest one more change?

dev->dinfo.bustype to dev->id.bus
dev->devinfo.id_vendor ro dev->id.vendor

It's no less informative, and looks much better. 

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

On Mon, 15 Apr 2002 20:22, Brad Hards wrote:
> On Mon, 15 Apr 2002 17:40, Vojtech Pavlik wrote:
> <snip>
>
> > Feel free to submit a patch. :) I'll most likely accept it.
>
> OK. I'll attack this problem in small chunks.
>
> Patch against evtest.c and patch against 2.4.19-pre6 attached, just
> attacking the EVIOCGID ioctl at this stage. Note that most of the kernel
> changes are in driver/usb.
Note: I missed a bit in the patch - should have incremented the version 
(EV_VERSION). Please don't forward the patch without adding that part.

Brad

Re: evdev types

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

On Mon, 15 Apr 2002 22:14, Vojtech Pavlik wrote:
<snip>
> God bless you for that. It is really needed. And I never can get me to
> write docs. :(
We each do what we are good at. You just keep coding...

> > I am doing hiddev and evdev in detail, since I think these are basically
> > undocumented. I've just done a couple of ioctl examples for each so far.
> > I am doing joystick by direct reference to the kernel docs - I may copy
> > the kernel files into the documentation (and docbook them) at a later
> > stage and add some examples, but the initial work work will be on evdev
> > and hiddev, and there is plenty there.
>
> That's exactly what's needed - actually joydev (and its api) is
> obsoleted by evdev.
I actually wrote the joystick bit first. I put the whole joystick section on 
the end of this email. It is more markup than content :)

> > What is missing is keyboard and mouse. I'd be willing to leave out
> > keyboard (because the stdin/scanf/getc semantic is probably enough.
>
> There isn't any keyboard API other than evdev and the console.
I was thinking about how to get the different modes (scancodes, keycodes, etc) 
for those apps that care about such stuff.

> > What I don't have
> > is mouse coverage. Does anyone have a good pointer to programming with
> > the PS2 variations? I was thinking about just pointing to libgpm, but
> > that doesn't really explain what comes out of /dev/input/mouse[0..30]
> > when you read.
>
>  /dev/input/mouse[0..30] simulates (quite exactly, both directions) the
> protocol of Microsoft IntelliMouse Explorer. But no new applications
> should use it, evdev is more powerful and easier to write for.
>
> I hope both mousedev and joydev will not be needed by 2.6 (2.8) or so.
Until it is removed, we need to document it :/
I'd like to have about the same amount of detail for mouse and keyboard 
programming as the following joystick section. And in the same way - which 
modules matter, what the device nodes do (for mouse/mice), and a pointer to 
some more data.

I certainly don't want to maintain documentation on weird, legacy interfaces 
:)

Brad


- - Joystick section follows.
<Sect1><title>The joystick interface</title>

<para>
The joystick interface is provided by the
<filename>joydev.o</filename> module, and the outputs appear on the
<filename>/dev/input/js0</filename>,
<filename>/dev/input/js1</filename> (and so on) device nodes.
</para>

<para>
More information on programming with the joystick interface is
provided in the kernel distribution (see the file
<filename>Documentation/input/joystick-api.txt</filename> in a current
kernel).
</para>

<Sect2><title>Force Feedback</title>
<para>
Information on programming force feedback effects for joysticks is
provided in the kernel distribution (see the file
<filename>Documentation/input/ff.txt</filename> in a current
kernel).
</para>
</Sect2>

</Sect1>