linuxconsole-dev

Re: New Input PS/2 driver

[Allan S. J. <sno...@on...>]

On Tuesday 02 October 2001 06:47, James Simmons wrote:
> Okay. It is not that new since I have been using it for several months now
> with now problems. I just ported from console project CVS to 2.4.10.
> Basically this patch address the issues people have been having with the
> current PS/2 driver. Plus it has the bonus of using the universal input
> api. It even allows for unpluging the keyboard with no problem and you can
> have two keybaord plugged in at the same time with no problems.

Nice, I've just tested it and it works mostly, at least more than ruby. 
Theres still problems with multiple keys. Holding shift and any of the 
insert/delete/home/end/page up/page down keys, results in two warnings:
unknown key(set 2, scancode 0x159 on input/0 ) pressed and released

Also when rebooting the input-kernel the BIOS reported keyboard error and I 
had to do a full power-off.

But I didnt see any off the autorepeat problems from ruby.

This is becoming a pretty good alternative, if we can keep up a functional 
patch against 2.4 until 2.5.

Regards.
`Allan

Re: New Input PS/2 driver

[Arndt S. <ab...@sr...>]

On Mon, Oct 01, 2001 at 09:47:53PM -0700, James Simmons wrote:
> [... Announcement of his new PS/2 input driver ...]
> http://www.transvirtual.com/~jsimmons/input-ps2.diff

Great! Does it, by chance, include the ability for bidirectional
communication with a PS/2 device from a user space program?

I want to write a keymap download program for Handykey's Twiddler2
(a chording keyboard connected to the PS/2 keyboard and mouse ports,
see http://www.handykey.com), for which this would be very handy.

Thank you,
Arndt

-- 
Arndt Schoenewald <ab...@sr...>

New Input PS/2 driver

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

Okay. It is not that new since I have been using it for several months now
with now problems. I just ported from console project CVS to 2.4.10.
Basically this patch address the issues people have been having with the
current PS/2 driver. Plus it has the bonus of using the universal input
api. It even allows for unpluging the keyboard with no problem and you can
have two keybaord plugged in at the same time with no problems. NOTE:
don't have both keyboard plugged in at boot time. It confusses them. 
The olnly thing which I haven't had time to do is support PS/2 based
keybards that don't use the standard IRQ and port ranges. Several mips
devices have this issue. The patch is 60 K so I posted a link. To use the 
keyboard driver you need to 

1) enable the input core and keyboard support in the input menu. 

2) In the character menu select PS/2 port support and i8042 aux+kbd
   controller. Their are hooks for other types of PS/2 "clones" on other
   platforms.

3) You have 3 different devices to select from. I don't think I have to
   explain them.

   XT keyboard.
   AT and PS/2 keyboards
   PS/2 mouse
   
Here is the diff.

http://www.transvirtual.com/~jsimmons/input-ps2.diff

P.S
  For assumment I have a funny movie clip in the same area(dancemonkeyboy.mpeg).

Re: Double MODULE_AUTHOR in evdev.c

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

> It seems the MODULE_AUTHOR and MODULE_DESCRIPTION appear twice in
> evdev.c. Once at the top, once at the bottom. The contents at the two
> locations are not exactly the same, btw.
> 
> Is that normal, or is it a mistake ? In my configuration, gcc complains
> about a redefinition of `__module_author'

That is a mistake. The bottom is what is in the current kernel but the new
stuff is much better description. So I placed the top stuff at the bottom.
Fixed now.

Double MODULE_AUTHOR in evdev.c

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

It seems the MODULE_AUTHOR and MODULE_DESCRIPTION appear twice in
evdev.c. Once at the top, once at the bottom. The contents at the two
locations are not exactly the same, btw.

Is that normal, or is it a mistake ? In my configuration, gcc complains
about a redefinition of `__module_author'

-- 
Johann Deneux

Re: Force feedback API

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

On Sun, Sep 30, 2001 at 06:37:47AM +0200, Oliver Hamann wrote:
> Hi!
> 
> Lessening bug 3 isn't any longer a reason to discuss about the API (see
> my previous mail in the mailing list). But i like it anyway - do you even?
> 
> Vojtech Pavlik wrote:
> > 
> > On Sat, Sep 29, 2001 at 02:03:11PM +0200, Johann Deneux wrote:
> > 
> > > I am not especially willing to make the distinction between effect
> > > packets and parameter packets visible to the user. Other protocoles
> > > may have a different understanding of what goes into an effect packet,
> > > and what goes into a parameter packet. What I could do is store the
> > > effects uploaded with ioctl in the driver. When other ioctls are
> > > performed to update an effect, I could analyse the difference and send
> > > only the necessary packets. Or I could change the API. Each call to
> > > ioctl would set one property of an effect:
> > >
> > > struct effect_property prop;
> > > prop.type = FF_PROP_ATTACK_LEVEL;
> > > prop.value = ...
> > > ioctl(fd, EVIOCSFF, &prop);
> > >
> > > prop.type = FF_PROP_ATTACK_DURATION;
> > > prop.value = ...
> > > ioctl(fd, EVIOCSFF, &prop);
> > > ...
> > >
> > > Instead of the one big ff_effect structure used now.
> > 
> > I think the differential uploading is nicest.
> 
> I think the nicest would be both, differential uploading _and_ property API.
> 
> I really like the property idea very much, it's cool! The structure will get
> binary incompatible when ever an extension is needed. Even, for compatible
> extensions, properties could get default values when they are not sent by
> the user on effect creation.
> 
> But to the example above: When will the parameter packet be sent to the
> device? On effect re-start or on each ioctl call? Both would'nt be good if
> we have a packet type, wich does not need an effect re-start and which has
> more than one parameter. So, what about sending an unsorted set of properties
> on each ioctl call? I mean something like this:
> 
> struct effect_property prop[3];
> prop[0].type = FF_PROP_ATTACK_LEVEL;
> prop[0].value = ...
> prop[1].type = FF_PROP_ATTACK_DURATION;
> prop[1].value = ...
> prop[2].type = FF_PROP_END;
> ioctl(fd, EVIOCSFF, prop);

Looks OK to me, too.

> In addition, to make the start/stop concept easier, you could add
> a property for it (e.g type=FF_PROP_PLAY, value=FF_START or FF_STOP),
> so that the effect is (re-)started or stoped on each reception of
> this property. Then the user could modify and re-start an effect
> by just one ioctl call.
> 
> Hmm, my next thought is to write the set of properties to the device,
> instead of calling ioctls. What about that?

I don't like this much. Ioctls shouldn't be used for starting/stopping
things, ioctls should be for setting things up. Just a matter of taste.

-- 
Vojtech Pavlik
SuSE Labs

Force feedback API

[Oliver H. <au...@od...>]

Hi!

Lessening bug 3 isn't any longer a reason to discuss about the API (see
my previous mail in the mailing list). But i like it anyway - do you even?

Vojtech Pavlik wrote:
> 
> On Sat, Sep 29, 2001 at 02:03:11PM +0200, Johann Deneux wrote:
> 
> > I am not especially willing to make the distinction between effect
> > packets and parameter packets visible to the user. Other protocoles
> > may have a different understanding of what goes into an effect packet,
> > and what goes into a parameter packet. What I could do is store the
> > effects uploaded with ioctl in the driver. When other ioctls are
> > performed to update an effect, I could analyse the difference and send
> > only the necessary packets. Or I could change the API. Each call to
> > ioctl would set one property of an effect:
> >
> > struct effect_property prop;
> > prop.type = FF_PROP_ATTACK_LEVEL;
> > prop.value = ...
> > ioctl(fd, EVIOCSFF, &prop);
> >
> > prop.type = FF_PROP_ATTACK_DURATION;
> > prop.value = ...
> > ioctl(fd, EVIOCSFF, &prop);
> > ...
> >
> > Instead of the one big ff_effect structure used now.
> 
> I think the differential uploading is nicest.

I think the nicest would be both, differential uploading _and_ property API.

I really like the property idea very much, it's cool! The structure will get
binary incompatible when ever an extension is needed. Even, for compatible
extensions, properties could get default values when they are not sent by
the user on effect creation.

But to the example above: When will the parameter packet be sent to the
device? On effect re-start or on each ioctl call? Both would'nt be good if
we have a packet type, wich does not need an effect re-start and which has
more than one parameter. So, what about sending an unsorted set of properties
on each ioctl call? I mean something like this:

struct effect_property prop[3];
prop[0].type = FF_PROP_ATTACK_LEVEL;
prop[0].value = ...
prop[1].type = FF_PROP_ATTACK_DURATION;
prop[1].value = ...
prop[2].type = FF_PROP_END;
ioctl(fd, EVIOCSFF, prop);

In addition, to make the start/stop concept easier, you could add
a property for it (e.g type=FF_PROP_PLAY, value=FF_START or FF_STOP),
so that the effect is (re-)started or stoped on each reception of
this property. Then the user could modify and re-start an effect
by just one ioctl call.

Hmm, my next thought is to write the set of properties to the device,
instead of calling ioctls. What about that?

- - - - - - -
Oliver Hamann

Re: Force feedback bugs

[Oliver H. <au...@od...>]

Hi,

Johann Deneux wrote:
> On Sat, 29 Sep 2001, Oliver Hamann wrote:
> > BUG 1: machine freeze
> > =====================
> >
> > BUG 2: force freeze
> > ===================
> >
> > BUG 3: force interrupts
> > =======================
> >
> > Somehow I tend to believe that the bug nests in the serial part,
> > because the highler level code looks so clear. My wheel is on rs232.
> > Did you ever encounter the bug with usb?
> 
> Yes, I do have the same problem with usb. I thought that maybe the
> cause was my asynchronous serial code. But even when coming back to
> a synchronous model, the problem subsists.

The fact that the bug is under both, rs232 and usb, motivated me to
take a careful look again into your send_packet function, and this
time i found it quickly. It's the circular buffer wrapping:

   memcpy(&iforce->xmit.buf[head],
          data,
          c);
   if (n != c) {
      memcpy(&iforce->xmit.buf[0],
             data,         <-- here's the mistake, should be: data+c
             n - c);
   }

It's the clear reason for bug 2 and 3. (proved by test)

Could this, somehow, even be the reason for bug 1?
Remember: the packet size is stored in the packet, the rs232 and usb
code depends on this. There may be great confusion when the size is
damaged by the circular buffer mistake.

- - - - - - 

Oliver Hamann

Re: Force feedback bugs

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

On Sat, Sep 29, 2001 at 02:03:11PM +0200, Johann Deneux wrote:
 
> I am not especially willing to make the distinction between effect packets
> and parameter packets visible to the user. Other protocoles may have a
> different understanding of what goes into an effect packet, and what goes
> into a parameter packet.
> What I could do is store the effects uploaded with ioctl in the
> driver. When other ioctls are performed to update an effect, I could
> analyse the difference and send only the necessary packets.
> Or I could change the API. Each call to ioctl would set one property of an
> effect:
> 
> struct effect_property prop;
> prop.type = FF_PROP_ATTACK_LEVEL;
> prop.value = ...
> ioctl(fd, EVIOCSFF, &prop);
> 
> prop.type = FF_PROP_ATTACK_DURATION;
> prop.value = ...
> ioctl(fd, EVIOCSFF, &prop);
> ...
> 
> Instead of the one big ff_effect structure used now.

I think the differential uploading is nicest.

-- 
Vojtech Pavlik
SuSE Labs

Force feedback bugs

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

I suggest we continue this discussion on the linuxconsole mailing
list. People on this list may be interested in the discussion.

Oliver and I have been talking about bugs in the force feedback code.

On Sat, 29 Sep 2001, Oliver Hamann wrote:

> OK, here we have two bugs so far:
> 
> BUG 1: machine freeze
> =====================
> 
> No, i did not encounter machine freezes, but I did not test for so many hours.
> I will send you more discussion about this bug on another day.
> 
> BUG 2: force freeze
> ===================
> 
> The device stops carrying out the commands from a sudden moment, the
> current force remains forever. Sometimes this happens right away after
> program start, so that a zero force is played forever. (I think this is
> one bug)
>

This bug I did not encounter with my AVB devices (Pegasus Top Shot and
their latest wheel)
 
> 
> BUG 3: force interrupts
> =======================
> 
> > > Another bug is, that the force often interrupts radomly for a few milliseconds.
> > 
> > I think I managed to track down the cause of this. The point is that I
> > have no idea how to work around this annoying behaviour. I guess I will
> > have to spy at the usb or rs232 traffic under windows.
> 
> Somehow I tend to believe that the bug nests in the serial part, because the
> highler level code looks so clear. My wheel is on rs232. Did you ever
> encounter the bug with usb? But read on, there is a solution to lessen bug 3.

Yes, I do have the same problem with usb. I thought that maybe the cause
was my asynchronous serial code. But even when coming back to a
synchronous model, the problem subsists.

> 
> > For your interest: There are two kinds of packets sent to the device to
> > describe an effect:
> > - some parameter packets. For example, one parameter is the magnitude of
> > the force, another parameter packet is the shape (attack + fade)
> > - an effect packet. It describes the direction of an effect, for how long
> > it should be played, which buttons can trigger it...
> 
> (Yes, i know the iforce protocol. Some years ago I even hacked it out with
> the idea to develop support for Linux. But it was one of the several projects
> that have been sorted out in lack of time... Now you are there ;o)
> 
> > Sending many parameter packets is ok, but sending an effect parameter too
> > often stops (sometimes) the playback. My intent is to prevent effect to
> > stop when they are not supposed to. Another solution would be to restart
> > the effect when it "crashes".
> > 
> > As the API is today, users do not know what will go into the parameter
> > packet, and will go in the effect one. I wonder if I should change that.
> 
> I think your "intent to prevent effect to stop when they are not supposed to"
> is a good idea. This could be done by adding an update function that only
> sends parameter packets. Additionally, to make this work with the magnitude
> packet, it would be nice if you could make it possible to send effects
> without paramter packets which are not essential (especially shape), because:

I am not especially willing to make the distinction between effect packets
and parameter packets visible to the user. Other protocoles may have a
different understanding of what goes into an effect packet, and what goes
into a parameter packet.
What I could do is store the effects uploaded with ioctl in the
driver. When other ioctls are performed to update an effect, I could
analyse the difference and send only the necessary packets.
Or I could change the API. Each call to ioctl would set one property of an
effect:

struct effect_property prop;
prop.type = FF_PROP_ATTACK_LEVEL;
prop.value = ...
ioctl(fd, EVIOCSFF, &prop);

prop.type = FF_PROP_ATTACK_DURATION;
prop.value = ...
ioctl(fd, EVIOCSFF, &prop);
...

Instead of the one big ff_effect structure used now.

> 
> In the hope to find out more about bug 2 and 3, i again removed the sending
> of the shape from iforce.c for a test. Moreover i hacked it all to send only
> a magnitude packet on each update. Unfortunately bug 2 is resistant against
> that. But it lessens bug 3: the force interrupt rate went down to about one
> per 5 seconds (at -u 25). In other words, it fixes 80% of bug 3. :-}
> Hm, on the other side, this possibly could be an indication for that bug 3
> may have something to do with the amount of packet traffic.
> By the way, with this test i have found bug 4 (see more below).

I do not know. If that was the case, we would have the bug occuring during 
high traffic communications, and disappear at lower ones. It just happens
more often at high than low traffics. May guess would be that a few 
packets are malformed, and those are the ones that cause interrupts.


> BUG 3: force interrupts - continued
> ===================================
> 
> > > The interrupt rate is about one per second, with large scatter.
> 
> New information: The force interrupt rate depends on the update rate.
> With -u 100 the interrupts are more frequent than with -u 1.
> 
> > > This bug can be
> > > felt well when starting ffcfstress with -a 0 and holding the wheel tight to the
> > > right or left. The feeling gets stronger when additionally moving the wheel
> > > slightly back and forth for avoidance of the friction. I'm sure that this is the
> > > bug i called "the forces are played scattered somehow" in one of the earlier mails.
> > 
> 
> BUG 4 - level -128
> ==================
> 
> This is an easier one. It's a feature of the iforce protocol, or it's
> a bug in my device (how is it with your device?).
> 
> When sending the signed byte -128 for the magnitude level to the device,
> the force is played as +128. Thus the range is not -128...+127, but
> -127...+128, in which +128 is encoded by 0x80. I tend to prefer that
> we should treat 0x80 as an undefined behavior and that we should reduce
> the range to -127...+127. Indeed, Windows never sends magnitude 0x80.
> 
> I really believe that this bug/feature is even for all other sigened
> byted level parameters. I know this for sure about the shape's attack
> level.

Hmm, I assumed the encoding of the negative values was the usual
complement to two, but I may have been wrong. Perhaps this could explain
the bug 2. While we expect the device to produce a force of value X, the
device understands something completely different. But this occurs only
for some values, most of values "feel" right.

> 
> The fix could be to replace lines like:
>   data[2] = HI(level);
> by for example:
>   data[2] = HI(level<0 ? level+255 : level);
>   /* This solution makes the roundings symmetrical: */
>   /* level +/-255 => data 0, level +/-256 => data +/-1 */
> 
> Another solution could be:
>   data[2] = HI(level<0 ? level+256 : level);
>   /* this one makes levels of -32768 valid */
> 
> When you have fixed it in iforce.c, you can simplify the code in ffcfstress.c
> 
> from:
> 
> 	/* Set force */
> 	if (force>0) {
> 		if (force>1.0) force=1.0;
> 		effect.u.constant.level=(short)(force*32767.0); /* only to be safe */
> 		effect.u.constant.direction=0xC000;
> 		effect.u.constant.shape.attack_level=(short)(force*32767.0); /* this one counts! */
> 		effect.u.constant.shape.fade_level=(short)(force*32767.0); /* only to be safe */
> 	}
> 	else {
> 		if (force<-1.0) force=-1.0;
> 		effect.u.constant.level=(short)(force*-32767.0); /* only to be safe */
> 		effect.u.constant.direction=0x4000;
> 		effect.u.constant.shape.attack_level=(short)(force*-32767.0); /* this one counts! */
> 		effect.u.constant.shape.fade_level=(short)(force*-32767.0); /* only to be safe */
> 	}
> 
> to:
> 
> 	/* Set force */
> 	if (force>1.0) force=1.0;
> 	else if (force<-1.0) force=-1.0;
> 	effect.u.constant.level=(short)(force*32767.0); /* only to be safe */
> 	effect.u.constant.shape.attack_level=(short)(force*32767.0); /* this one counts! */
> 	effect.u.constant.shape.fade_level=(short)(force*32767.0); /* only to be safe */
> 
> Thus, bug 4 was the reason why i needed to keep the level values positive.

Ok, I will add your fix when I come back home.

PS: ffcfstress sources attached.

-- 
Johann Deneux

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

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

> That said, i guess the problem here would be the same as for generic accels in
> the kernel, that is it will not go in. Most probably, a userland library would
> need to be created which could cooperate with the fbdev driver.

I agree. I think only support for hardware overlays should be. Most
hardware even for embedded devices support overlays. As for mpeg coding
that is a userland issue.

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code (was: The futureof framebuffer)

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

> Now, I still need to get pm3fb working in ruby :-(

I will play with  it this weekend.

Re: AGAINST-2.4.8 and MODULE_LICENSE

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

On Fri, Sep 28, 2001 at 10:53:53AM +0200, Romain Dolbeau wrote:

> Hello,
> 
> there's a problem with all and every file in drivers/input.
> They all contain a 'MODULE_LICENSE', which exist only from
> 2.4.10 onward. I fixed one (i'll back out the patch) before
> noticing they were all wrong.
> 
> So should 2.4.10 be integrated, or all MODULE_LICENSE
> removed ?

Oops, I've done it again. Sorry. I think it doesn't make sense to remove
MODULE_LICENSE everywhere, because it'll have to be added again later.

So the options are:

1) Port ruby to 2.4.10
2) Add MODULE_LICENSE to ruby's own module.h

I'd prefer #1.

-- 
Vojtech Pavlik
SuSE Labs

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

[Michel <mic...@ii...>]

Sven wrote:

> > I'm not sure - but what about having a support of hardware accelerated
> > decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag and so
> > on)
> > Unfortunatelly I never saw any opensource project which has implementation
> > of such things but if you know how it should be implemented then such
> > extensions are gladly accepted too.
> 
> mmm, The Xv extension to X does this.

No, all it can do is colorspace conversion and scaling.

The brand new XvMC extension does this, the problem is the lack of
documentation. There is only one implementation for i81x (done by an Intel
employee) and no players support it yet.


> That said, i guess the problem here would be the same as for generic accels
> in the kernel, that is it will not go in. Most probably, a userland library
> would need to be created which could cooperate with the fbdev driver.

Like http://directfb.org ?


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

[Romain D. <do...@ir...>]

Nick Kurshev wrote:

> But in this case fbdev will useless and meaningless toy which was
> born only for linux-logo :(

No, fbdev is required as a system console on many system ;
I _believe_ Geert wrote the original FB code so that some
m68k boxes may have a console. It's mandatory at least
on linux/mac68k and linux/*ppc...

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

[Nick K. <nic...@ma...>]

Hello, Romain!
On Fri, 28 Sep 2001 10:06:48 +0200, you wrote:

> Nick Kurshev wrote:
> 
> > I'm not sure - but what about having a support of hardware accelerated
> > decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag and so on)
> > Unfortunatelly I never saw any opensource project which has implementation
> > of such things but if you know how it should be implemented then such extensions
> > are gladly accepted too.
> 
> I don't know how to, as I don't have knowledge of MPEG decoding, and
> the card I own can't do it anyway (maybe It can, but I don't have
> the docs, are Formac redirect me to 3Dlabs and 3Dlabs doesn't
> answer my mail - I thought things were going well when they
> suddenly stopped to answer my mail...)
> 
> Anyway, I'm not sure adding all and every possible features
> to the FB driver will be seen kindly by those-in-charge
> (aka Linus T. and maybe Alan C.) I'm not even sure they'll
> agree on video overlay...
> 
But in this case fbdev will useless and meaningless toy which was
born only for linux-logo :(
But Linux-logo could be displayed through vesafb without native
drivers and NLS problems. Simply because after displaying logo
vesafb should be terminated.

> -- 
> DOLBEAU Romain               | l'histoire est entierement vraie, puisque
> ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
> do...@ir...             |           -- Boris Vian
> 


Best regards! Nick

AGAINST-2.4.8 and MODULE_LICENSE

[Romain D. <do...@ir...>]

Hello,

there's a problem with all and every file in drivers/input.
They all contain a 'MODULE_LICENSE', which exist only from
2.4.10 onward. I fixed one (i'll back out the patch) before
noticing they were all wrong.

So should 2.4.10 be integrated, or all MODULE_LICENSE
removed ?

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code (was: The futureof framebuffer)

[Romain D. <do...@ir...>]

James Simmons wrote:

> Great! I look forward to it.

Done. it's in linux/include/linux/fbvid.h

Now, I still need to get pm3fb working in ruby :-(

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

[Romain D. <do...@ir...>]

Nick Kurshev wrote:

> I'm not sure - but what about having a support of hardware accelerated
> decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag and so on)
> Unfortunatelly I never saw any opensource project which has implementation
> of such things but if you know how it should be implemented then such extensions
> are gladly accepted too.

I don't know how to, as I don't have knowledge of MPEG decoding, and
the card I own can't do it anyway (maybe It can, but I don't have
the docs, are Formac redirect me to 3Dlabs and 3Dlabs doesn't
answer my mail - I thought things were going well when they
suddenly stopped to answer my mail...)

Anyway, I'm not sure adding all and every possible features
to the FB driver will be seen kindly by those-in-charge
(aka Linus T. and maybe Alan C.) I'm not even sure they'll
agree on video overlay...

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

[Sven <lu...@dp...>]

On Fri, Sep 28, 2001 at 09:48:52AM +0400, Nick Kurshev wrote:
> Hello, Romain!
> On Thu, 27 Sep 2001 11:31:25 +0200, you wrote:
> 
> > Romain Dolbeau wrote:
> > 
> > > Still, I guess I should use them ; I think I could add
> > > a 'number of FOURCC supported' field in the
> > > "struct fb_vidoverlay_avail", and add (yet) another
> > > ioctl to get only the variable-length FOURCC list.
> > 
> > F-up myself, here's an updated file. The sample implementation
> > in pm3fb compile (not near thebox, can't test it yet :-)
> > 
> > Any comment/criticism/improvement/advice very much welcome.
> > 
> > -- 
> > DOLBEAU Romain               | l'histoire est entierement vraie, puisque
> > ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
> > do...@ir...             |           -- Boris Vian
> Well, it seems - o'k.
> I'm not sure - but what about having a support of hardware accelerated
> decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag and so on)
> Unfortunatelly I never saw any opensource project which has implementation
> of such things but if you know how it should be implemented then such extensions
> are gladly accepted too.

mmm, The Xv extension to X does this.

That said, i guess the problem here would be the same as for generic accels in
the kernel, that is it will not go in. Most probably, a userland library would
need to be created which could cooperate with the fbdev driver.

Friendly,

Sven Luther

Re: FB, video, FOURCC code

[Nick K. <nic...@ma...>]

Hello, Romain!
On Thu, 27 Sep 2001 11:31:25 +0200, you wrote:

> Romain Dolbeau wrote:
> 
> > Still, I guess I should use them ; I think I could add
> > a 'number of FOURCC supported' field in the
> > "struct fb_vidoverlay_avail", and add (yet) another
> > ioctl to get only the variable-length FOURCC list.
> 
> F-up myself, here's an updated file. The sample implementation
> in pm3fb compile (not near thebox, can't test it yet :-)
> 
> Any comment/criticism/improvement/advice very much welcome.
> 
> -- 
> DOLBEAU Romain               | l'histoire est entierement vraie, puisque
> ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
> do...@ir...             |           -- Boris Vian
Well, it seems - o'k.
I'm not sure - but what about having a support of hardware accelerated
decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag and so on)
Unfortunatelly I never saw any opensource project which has implementation
of such things but if you know how it should be implemented then such extensions
are gladly accepted too.

Best regards! Nick

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code (was: The future of framebuffer)

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

> I'll try to add some more explanations/comments and I'll commit the
> stuff to the CVS tree. Then I'll need to port the -vidoverlay stuff from
> regular pm3fb... and hope other drivers will follow ;-)

Great! I look forward to it.

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code (was: The future of framebuffer)

[<dol...@cl...>]

> I have no problem with it. This way it can evolve a little bit before it
> becomes part of the main stream.

I'll try to add some more explanations/comments and I'll commit the
stuff to the CVS tree. Then I'll need to port the -vidoverlay stuff from
regular pm3fb... and hope other drivers will follow ;-)

-- 
Romain DOLBEAU               |  Energy derives from both
ENS Cachan / Ker Lann        |    the plus and negative
Thesard IRISA / CAPS         |       -- Metallica
dol...@cl...    |        in 'Eye of the Beholder'

Re: [Linux-fbdev-devel] The future of framebuffer

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

> > > Is this console program or kernel issue?
> > > fbcon is ready for single byte characters, and
> > > jfbterm is ready for more complex language like UTF, EUC, ISO-2022.
> > > Also console-tools is becoming ready for single byte characters and
> > > UTF-8. But I've never seen multibyte characters with default
> > > terminal (with console-tools).
> > > 
> > > -- gotom
> > > 
> > As I see NLS depends on drivers/video/font_8x??.c which were generated by cpi2font.
> > Curently Linux has only english version of these files.
> 
> Right. Currently there is only ISO-8859-1 characters.
> Is it useful to add more characters for ISO-8859-x or
> KOI-8 people ?
> I'm interesting, but I don't know whether there are some demands or not.
> 
> But, adding more complex characters like EUC and ISO-2022
> is more difficult, because they are multibyte characters.
> Handling them is some more hack.
> Their character file is very big because their font have
> more than 30000. Full or partial UTF-8 support invites
> this problem. These days linux has large nls file in fs/nls,
> so I think it's ok, but someone complain about this issue...

The linux console is based VGA text hardware which can only do 8 bit fonts
and only display at most 512 different fonts. So the very backbone of the
console system is limited. I like to see this expanded for 2.5.X. The
framebuffer system could handle it very nicely. Just systems like MDA and
VGA couldn't. Now I don't advocate placing 10,000 characters in the
kernel. I do support have support for them and then having userland tools
that can load such font sets for use. 

Re: FB, video, FOURCC code (was: The future of framebuffer)

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

> BTW, what do the linux-console folks think of adding
> video overlay support to Ruby ?

I have no problem with it. This way it can evolve a little bit before it
becomes part of the main stream.