LCDproc development and user support list

Text archives Help


[Lcdproc] MtxOrb v0.4.5 - bug fixes


Chronological Thread 
  • From: lcdproc AT neko.me.uk (Chris Lansley)
  • Subject: [Lcdproc] MtxOrb v0.4.5 - bug fixes
  • Date: Sun Sep 12 12:29:02 2004

Hi David,

Thanks for reply. I'm a bit busy at the moment so I'm sending you the =
.c file.
When I'm a little less busy I will try to be more useful!

From memory:
- The old driver does strcpy on the framebuffer which is silly as it =
can contain 0 (first custom char).
- It was using 254 as a dirty char - which is ok but then it allowed =
the 254 to be sent
out - which is really silly as 254 is the command code for Matrix =
Orbital.
- The custom char dynamic allocation was really broken and kept =
reusing slots even though
there were others that were not even used yet.
- The bar graphs use 255 rather than defining a full custom char - =
this gives a strange look to
graphs as 255 is not a completely full block.
- sorry can't remember the rest, at the moment.



Chris.

> -----Original Message-----
> From:
> lcdproc-admin AT lists.omnipotent.net
> [mailto:lcdproc-admin AT lists.omnipotent.net]On
> Behalf Of David GLAUDE
> Sent: 12 September 2004 13:08
> To: Chris Lansley
> Cc:
> lcdproc AT lists.omnipotent.net
> Subject: Re: [Lcdproc] MtxOrb v0.4.5 - bug fixes
>=20
>=20
> Yes,
> 1) BigNums is a bit buggy and has strange side effect. Nice if you can =

> fix them.
> 2) If the screen and the framebuffer do desynchronise, then some area=20
> might not be updated since it is believed that it countain the right=20
> thing already... so this might be a consequence of 1
> 3) This is a feature, not a bug...
>=20
> The solution to 3) was supposed to share between all driver code some=20
> kind of custom char cache. That idea was developped talking about what =

> should be in 0.5.
>=20
> You should find better caracter caching code inside Crystal Fontz =
driver=20
> I guess. I did not want to copy that code into MO since it require to =
be=20
> made reusable.
>=20
> Also, it is not really recommanded to do change in 0.4.x.
>=20
> I would say that the bug fix for 1 and 2 are welcome into 0.4.x IF you =

> do them into 0.5 too.
>=20
> Solution to 3 should be discussed a bit more and maybe not=20
> welcome in 0.4.x
>=20
> Show us your GPL code (patch agains the CVS) so that we can discuss =
what=20
> you did.
>=20
> David GLAUDE
>=20
> Chris Lansley wrote:
>=20
> > [This email is referring to LCDproc version 0.4.5 (and maybe=20
> some before that)]
> >=20
> > Hi,
> >=20
> > I've noticed a number of bugs in the MtxOrb driver - I've=20
> examined the code and have some=20
> > fixes available.
> >=20
> > I've noticed:=20
> > 1, BigNums can cause random characters to appear (or=20
> for areas not to be cleared).
> > [From examining the code - almost anything could go=20
> wrong on the
> > Matrix Orbital side; because the driver is sending=20
> random command sequences]
> >=20
> > 2, Areas of the screen stop updating, and some random=20
> characters may appear.
> >=20
> > 3, Special chars (user defined characters) are being=20
> redefined even though they
> > are already defined (ie. sends unneeded updates=20
> over serial link).=20
> > [This could be a client problem - not sure yet]
> >=20
> > Before I do anything with these fixes - I need to know if=20
> other Matrix Orbital users
> > are seeing these problems. Secondly I would like some=20
> people to offer to be beta
> > testers for the fixed driver - just to be sure that my=20
> changes improve the driver!
>=20
> --=20
> Don't let computer expert control election...
> Endorse: http://www.free-project.org/resolution/
> For Belgium: http://www.poureva.be/
>=20
> _______________________________________________
> LCDproc mailing list
> LCDproc AT lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>=20







Archive powered by MHonArc 2.6.18.

Top of page