linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] Re: [PATCH] fbdev updates.

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

On Fri, Jul 05, 2002 at 10:16:28AM -0700, James Simmons wrote:
> > On Fri, Jul 05, 2002 at 10:53:35AM +0200, Geert Uytterhoeven wrote:
> > > If you have an `asymmetric' dual-head chipset (both heads are not independent,
> > > and/or have different capabilities), you'll have 2 info structures, with one
> > > shared par. So info and par cannot be combined.
> >
> > That may be true for such systems.  I don't believe in imposing such
> > restrictions on drivers that can _never ever_ fall into that category.
> 
> Imposing a standard set of rules to a subsystem. What insane person would
> ever do that?

Imposing a set of useless features on hardware that can not support it
by design.  Yes, that's sensible, oh yes.

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

[Linux-fbdev-devel] Re: [PATCH] fbdev updates.

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

On Fri, Jul 05, 2002 at 10:14:12AM -0700, James Simmons wrote:
> > First, I detest the idea of "fix", "var", "par" and "info".  Specifically
> > the "par" crap. Intensely.
> 
>    Why? Should each driver have their own structs that are completely
> different then? In this case you would be better off doing something like
> newport_con.c.
> 
>     We pretty much have this today. Each driver has so much excess code
> because they want to create their own special structs. Lost of bloat for
> no reason! I will NOT put up with that anymore!!!! Sorry!

James, you're OTT here.  Look at what the structure contains.  You will
notice that it's very specific to the driver.  Drivers have the implicit
right to define what data they need to maintain their internal state;
the core has no right to define that.

If you're going to be this hard headed about this, YOU can take over
complete maintainence of ALL framebuffer drivers.  I'll direct ALL
problems to you to solve.

It's part of the deal.  Either you allow driver writers to cleanly code
the way they see fit, or you take over maintainence of those drivers.
You break it, you fix it.  What's it to be?

> > "par" and "info" should be combined IMO,
> > which my framebuffer drivers do.
> 
> No!!!! This is one of the reasons we have the mess we have!! Look at how
> much code that could be removed from the standard drivers into fbmem.c and
> fbcon.c.

sa1100fb was already cleaned up in the way YOU wanted to remove most of
the junk back in the 2.4 days.  I consider it to be extremely clean.  Or
used to be.  All that now remains in there has very little commonality
between the drivers.

When there is ONE and only ONE framebuffer device possible, it makes
sense to try to combine structures as much as possible, especially
when:

1. allocation of structures has overhead.
2. you can get some performance advantage from combining such structures.
3. you're running on an embedded platform and are trying not to waste
   ANY resources.

> > Secondly, I think you're completely confused above.  lccr0 and lccr3 have
> > nothing to do with some "generic struct fb_info".  They hold the base
> > register values for two of the SA1100 control registers.
> >
> > Thirdly, you didn't delete them.  You _moved_ them within the structure.
> > They therefore served zero functional purpose.
> 
> If you could send me a patch I would be happy.

Patch for what?  I _really_ don't understand your request here.

> > Fourthly, nothing but the sa1100fb driver has any business accessing the
> > elements around these two both before and after the move.
> 
> True which is why things like that go into par.

Then why are you trying to share the par between others (as you said in
a previous message)?

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

Re: [Linux-fbdev-devel] Re: [PATCH] fbdev updates.

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

> > > That may be true for such systems.  I don't believe in imposing such
> > > restrictions on drivers that can _never ever_ fall into that category.
> >
> > Then just store your par in your info.
>
> Err, that's what I _am_ doing.  However, James has converted my info to
> a par and reordered some elements without any reason.

Read my other email. Lets see the reason. Modularity of the subsystem.
Code reduction.

Re: [Linux-fbdev-devel] Re: [PATCH] fbdev updates.

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

> On Fri, Jul 05, 2002 at 10:53:35AM +0200, Geert Uytterhoeven wrote:
> > If you have an `asymmetric' dual-head chipset (both heads are not independent,
> > and/or have different capabilities), you'll have 2 info structures, with one
> > shared par. So info and par cannot be combined.
>
> That may be true for such systems.  I don't believe in imposing such
> restrictions on drivers that can _never ever_ fall into that category.

Imposing a standard set of rules to a subsystem. What insane person would
ever do that?

[Linux-fbdev-devel] Re: [PATCH] fbdev updates.

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

> First, I detest the idea of "fix", "var", "par" and "info".  Specifically
> the "par" crap. Intensely.

   Why? Should each driver have their own structs that are completely
different then? In this case you would be better off doing something like
newport_con.c.

    We pretty much have this today. Each driver has so much excess code
because they want to create their own special structs. Lost of bloat for
no reason! I will NOT put up with that anymore!!!! Sorry!

> "par" and "info" should be combined IMO,
> which my framebuffer drivers do.

No!!!! This is one of the reasons we have the mess we have!! Look at how
much code that could be removed from the standard drivers into fbmem.c and
fbcon.c.

We should have
					 focus on
struct vc_data    struct fb_info         struct xxx_par

[ fbcon.c]        [ fbmem.c]             [ fbdev driver ]

This makes for a nice modular system. It allows for fbdev to exist without
fbcon. Ideally fbmem could even be modular. Insmod the core driver.
Insmod fbmem.o and you have the fbdev interface. You could then rmmod
fbmem.o and do dri.o. Now with the same core driver you have the DRI
interface. Or you could do both drivers at the same time. Eventually I
will combine both interfaces but that will take some time.

> Secondly, I think you're completely confused above.  lccr0 and lccr3 have
> nothing to do with some "generic struct fb_info".  They hold the base
> register values for two of the SA1100 control registers.
>
> Thirdly, you didn't delete them.  You _moved_ them within the structure.
> They therefore served zero functional purpose.

If you could send me a patch I would be happy.

> Fourthly, nothing but the sa1100fb driver has any business accessing the
> elements around these two both before and after the move.

True which is why things like that go into par.

> Ehh?  That's got nothing to do with cpufreq.  The reason we have the
> cpufreq interface in sa1100fb is that the base clock rate for the LCD
> controller on this chip is derived from the CPU core clock.  You change
> the core clock, you have to reprogram the pixel clock divisor.

Other devices besides the SA1100 does this as well. I knew this and this
reason lead me to originally place it into struct fb_info. Later I
realized it was a bad idea.

Re: [Linux-fbdev-devel] Re: [PATCH] fbdev updates.

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

On Fri, Jul 05, 2002 at 11:39:24AM +0200, Geert Uytterhoeven wrote:
> On Fri, 5 Jul 2002, Russell King wrote:
> > On Fri, Jul 05, 2002 at 10:53:35AM +0200, Geert Uytterhoeven wrote:
> > > If you have an `asymmetric' dual-head chipset (both heads are not independent,
> > > and/or have different capabilities), you'll have 2 info structures, with one
> > > shared par. So info and par cannot be combined.
> > 
> > That may be true for such systems.  I don't believe in imposing such
> > restrictions on drivers that can _never ever_ fall into that category.
> 
> Then just store your par in your info.

Err, that's what I _am_ doing.  However, James has converted my info to
a par and reordered some elements without any reason.

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

Re: [Linux-fbdev-devel] Re: [PATCH] fbdev updates.

[Geert U. <ge...@li...>]

On Fri, 5 Jul 2002, Russell King wrote:
> On Fri, Jul 05, 2002 at 10:53:35AM +0200, Geert Uytterhoeven wrote:
> > If you have an `asymmetric' dual-head chipset (both heads are not independent,
> > and/or have different capabilities), you'll have 2 info structures, with one
> > shared par. So info and par cannot be combined.
> 
> That may be true for such systems.  I don't believe in imposing such
> restrictions on drivers that can _never ever_ fall into that category.

Then just store your par in your info.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] Re: [PATCH] fbdev updates.

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

On Fri, Jul 05, 2002 at 10:53:35AM +0200, Geert Uytterhoeven wrote:
> If you have an `asymmetric' dual-head chipset (both heads are not independent,
> and/or have different capabilities), you'll have 2 info structures, with one
> shared par. So info and par cannot be combined.

That may be true for such systems.  I don't believe in imposing such
restrictions on drivers that can _never ever_ fall into that category.

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

Re: [Linux-fbdev-devel] Re: [PATCH] fbdev updates.

[Geert U. <ge...@li...>]

On Fri, 5 Jul 2002, Russell King wrote:
> On Thu, Jul 04, 2002 at 09:05:40PM -0700, James Simmons wrote:
> > > 2. I've no idea why you moved "lccr0" and "lccr3" in sa1100fb.h - this
> > >    looks like noise to me.
> > 
> > Ah the idea of a par and using generic struct fb_info. A few reasons. One
> > I noticed people having fields inside their struct xxxfb_info that was
> > already there in the generic struct fb_info. By making a strick rule I
> > hope to avoid that ugly mess. The second reason is eventually I like to
> > combine DRI and the fbdev layer. This was both interfaces could use the
> > same struct xxx_par. That is a 2.7 thing but I like to prepare now for
> > this. For the SA1100 this is not really needed but I still like to enforce
> > this rule and we still can take advantage of the nice generic functions in
> > fbgen.c.
> 
> First, I detest the idea of "fix", "var", "par" and "info".  Specifically
> the "par" crap.  Intensely.  "par" and "info" should be combined IMO,
> which my framebuffer drivers do.

If you have an `asymmetric' dual-head chipset (both heads are not independent,
and/or have different capabilities), you'll have 2 info structures, with one
shared par. So info and par cannot be combined.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[Linux-fbdev-devel] Re: [PATCH] fbdev updates.

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

On Thu, Jul 04, 2002 at 09:05:40PM -0700, James Simmons wrote:
> > 2. I've no idea why you moved "lccr0" and "lccr3" in sa1100fb.h - this
> >    looks like noise to me.
> 
> Ah the idea of a par and using generic struct fb_info. A few reasons. One
> I noticed people having fields inside their struct xxxfb_info that was
> already there in the generic struct fb_info. By making a strick rule I
> hope to avoid that ugly mess. The second reason is eventually I like to
> combine DRI and the fbdev layer. This was both interfaces could use the
> same struct xxx_par. That is a 2.7 thing but I like to prepare now for
> this. For the SA1100 this is not really needed but I still like to enforce
> this rule and we still can take advantage of the nice generic functions in
> fbgen.c.

First, I detest the idea of "fix", "var", "par" and "info".  Specifically
the "par" crap.  Intensely.  "par" and "info" should be combined IMO,
which my framebuffer drivers do.

Secondly, I think you're completely confused above.  lccr0 and lccr3 have
nothing to do with some "generic struct fb_info".  They hold the base
register values for two of the SA1100 control registers.

Thirdly, you didn't delete them.  You _moved_ them within the structure.
They therefore served zero functional purpose.

Fourthly, nothing but the sa1100fb driver has any business accessing the
elements around these two both before and after the move.

In total, the change serves ZERO purpose and is therefore noise.

> > 5. I strongly disagree with your apparant decision to make the cpufreq
> >    part of the generic framebuffer core (by apparantly adding the notifier
> >    block to the core fb_info structure).  Firstly, you've broken sa1100fb.c
> >    by not including the relevant definition in fb_info (ok, so cpufreq
> >    stuff isn't in Linus' tree yet).  Secondly, it isn't something that all
> >    framebuffers require; its only required on SoC devices where the hardware
> >    designers have been stingy.  As such, we should NOT penalise the x86
> >    people by adding random useless garbage to structures that they're never
> >    going to use.
> 
> I completely agree. I'm going to remove that. Originally I thought about
> making it generic for everyone because I have seen other platforms
> (Mips Au1000 with Epson 1385 framebuffers) do something similar. Then I
> realized not everyone needs it and also it is possible that devices with
> more than one framebuffer might use the same pixclock frequency.

Ehh?  That's got nothing to do with cpufreq.  The reason we have the
cpufreq interface in sa1100fb is that the base clock rate for the LCD
controller on this chip is derived from the CPU core clock.  You change
the core clock, you have to reprogram the pixel clock divisor.

> Dumb but
> I have seen alot of cards share the accel engine and/or CRTC registers
> between two different framebuffers on the same piece of hardware. So it
> belongs in par.

Again, I think this is another misplaced reason; that's irrelevant to
cpufreq.

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

Re: [Linux-fbdev-devel] pm3fb driver is ok in 2.5.24

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

James Simmons wrote:
> 
> > So pm3fb won't work anymore I guess (due to the ultimate brokenness
> > of linux on PowerPC I haven't yet ported pm3fb to the new API).
> 
> Have you tried the BK ppc tree for 2.5.X? Dose it work? I noticed there
> were some updates just a few hours ago.

My usual tree (BenH) has a 2.5 variant, locked a 2.5.8pre3...
I'm willing to try another one, but I'm still disapointed
that regular Linus kernel can't even compile main.c on PPC.

Just tried: all rsync access seems locked on 2.5.8pre3,
and of course debian doesn't have bitkeeper in packages.
And bitkeeper download site isn't really user-friendly
(guess the "let's register yourself before download"
attitude explain why it's not in debian, and not on my
system either).Xorsis (ppckernel.org) has nothing
beyond 2.4 ATM.

Well, I'm still waiting for an accessible, ppc-usable
2.5.[something big enough] before I can port pm3fb.

-- 
DOLBEAU Romain               | Who'd believe we'd spend more            
ENS Cachan / Ker Lann        | Shippin' drugs and guns                  
Thesard IRISA / CAPS         | Than to educate our sons?                
dol...@cl...    |   -- Megadeth, 'Youthanasia'

[Linux-fbdev-devel] Re: cfb_{copyarea,fillrect}()

[Geert U. <ge...@li...>]

On Thu, 4 Jul 2002, James Simmons wrote:
> > Other comments/notes:
> >   - Shouldn't cfb_fillrect() use the pseudo_palette in DIRECTCOLOR mode?
> 
> ??? I thought you had to go threw the DAC to get values.

Yes, but you have to do that for _each_ color component. So you have to use
pixel value (i, i, i), not (0, 0, i) (depending on the order of the components)
like the current code does.

> >   - I think the cfb_*() routines can easily be modified to work for bpp < 8,
> >     and for bpp == 24:
> 
> It doesn't work for bpp < 4 for you? It should work for those as well. Bpp

Note that I didn't try that.

> 24 is a bit more trick if we want to do word align access to the
> framebuffer.
> 
> >       o initialize src/dst indices to be bit indices instead of byte indices
> >       o remove shifts by 3
> >       o n is number of bits to copy/fill
> 
> Hm. I have to work up so psuedo code to try that idea out.

The main idea is to do an optimized bitcopy, not a bytecopy. Then it works for
all values of bpp:

    void bitcpy(unsigned long *dst, int dst_idx, unsigned long *src,
		int src_idx, int nbits);

{dst,src}_idx are bit indices (0 == MSB, 31 or 63 = LSB), nbits is the number
of bits to copy.

The same is true for fillrect, there you want an optimized bitset().

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] pm3fb driver is ok in 2.5.24

[Sven L. <lu...@la...>]

On Thu, Jul 04, 2002 at 07:38:27PM -0700, James Simmons wrote:
> 
> > > api. I'm going to removal the old fbgen code soon.
> >
> > how soon, and is there documentation or sample code for the changed api
> > ?
> 
> In the next few days. Take a look at several drivers that have been ported
> over. Plus take a look at skeletonfb.c. It details alot. If you have
> furthur questions feel free to ask.

Well, the only problem is that i don't have much time :(((

But i will have a look at it.

do i need to get the bk tree, or can i start working with the 2.5.24
linus tree i now have ?

Maybe there is a patch available somewhere ?

> > BTW, i suppose now it will be easier to implement dual head with a dual
> > output board ?
> 
> Yes :-) ON struct fb_info for each framebuffer and a struct xxx_par for
> the hardware. In this case your xxx_par struct would be shared betweem
> each struct fb_info.

:)))

Friendly,

Sven Luther

[Linux-fbdev-devel] Re: [PATCH] fbdev updates.

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

> 1. It would appear to break sa1100 inverse colourmap stuff.  There are LCD
>    panels out there where it is a rather fundamental requirement to write
>    the palette with "inverted" colourmap values.

Okay. Fixed.

> 2. I've no idea why you moved "lccr0" and "lccr3" in sa1100fb.h - this
>    looks like noise to me.

Ah the idea of a par and using generic struct fb_info. A few reasons. One
I noticed people having fields inside their struct xxxfb_info that was
already there in the generic struct fb_info. By making a strick rule I
hope to avoid that ugly mess. The second reason is eventually I like to
combine DRI and the fbdev layer. This was both interfaces could use the
same struct xxx_par. That is a 2.7 thing but I like to prepare now for
this. For the SA1100 this is not really needed but I still like to enforce
this rule and we still can take advantage of the nice generic functions in
fbgen.c.

> 3. I think you replaced "fbi" too many times:
> 	+/* Fake monspecs to fill in infonfo structure */

Fixed.

> 4. You're also merging in cpufreq changes from my tree in this patch;
>    however I was going to send these to Linus along with the cpufreq
>    submission so no problem.

Just what was in sa1100fb.c. I grabbed that version of the driver from
your tree sinc ethe stuff in Linus tree didn't compile at the time.

> 5. I strongly disagree with your apparant decision to make the cpufreq
>    part of the generic framebuffer core (by apparantly adding the notifier
>    block to the core fb_info structure).  Firstly, you've broken sa1100fb.c
>    by not including the relevant definition in fb_info (ok, so cpufreq
>    stuff isn't in Linus' tree yet).  Secondly, it isn't something that all
>    framebuffers require; its only required on SoC devices where the hardware
>    designers have been stingy.  As such, we should NOT penalise the x86
>    people by adding random useless garbage to structures that they're never
>    going to use.

I completely agree. I'm going to remove that. Originally I thought about
making it generic for everyone because I have seen other platforms
(Mips Au1000 with Epson 1385 framebuffers) do something similar. Then I
realized not everyone needs it and also it is possible that devices with
more than one framebuffer might use the same pixclock frequency. Dumb but
I have seen alot of cards share the accel engine and/or CRTC registers
between two different framebuffers on the same piece of hardware. So it
belongs in par.

[Linux-fbdev-devel] Re: cfb_{copyarea,fillrect}()

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

> It also adds 64-bit support to cfb_copyarea().

Thanks. Added to BK tree.

> Other comments/notes:
>
>   - Shouldn't cfb_fillrect() use the pseudo_palette in DIRECTCOLOR mode?

??? I thought you had to go threw the DAC to get values.

>   - I think the cfb_*() routines can easily be modified to work for bpp < 8,
>     and for bpp == 24:

It doesn't work for bpp < 4 for you? It should work for those as well. Bpp
24 is a bit more trick if we want to do word align access to the
framebuffer.

>       o initialize src/dst indices to be bit indices instead of byte indices
>       o remove shifts by 3
>       o n is number of bits to copy/fill

Hm. I have to work up so psuedo code to try that idea out.

>   - I think that line length is not guaranteed to be a multiple of
>     sizeof(unsigned long). Hence a different start/end mask per line is
>     possible as well.

Missed that one.

Re: [Linux-fbdev-devel] [PATCH] fbdev updates.

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

> That's OK as long as we know that the drivers which are converted are 100%
> converted and can be taken as an example.

Okay. I will push the changes tomorrow. Take a look at skeletonfb.c for
info :-0

Re: [Linux-fbdev-devel] pm3fb driver is ok in 2.5.24

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

> So pm3fb won't work anymore I guess (due to the ultimate brokenness
> of linux on PowerPC I haven't yet ported pm3fb to the new API).


Have you tried the BK ppc tree for 2.5.X? Dose it work? I noticed there
were some updates just a few hours ago.

Re: [Linux-fbdev-devel] pm3fb driver is ok in 2.5.24

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

> > api. I'm going to removal the old fbgen code soon.
>
> how soon, and is there documentation or sample code for the changed api
> ?

In the next few days. Take a look at several drivers that have been ported
over. Plus take a look at skeletonfb.c. It details alot. If you have
furthur questions feel free to ask.

> BTW, i suppose now it will be easier to implement dual head with a dual
> output board ?

Yes :-) ON struct fb_info for each framebuffer and a struct xxx_par for
the hardware. In this case your xxx_par struct would be shared betweem
each struct fb_info.


>
> Friendly,
>
> Sven Luther
> >
>

[Linux-fbdev-devel] Re: [PATCH] fbdev updates.

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

On Mon, Jul 01, 2002 at 10:48:41AM -0700, James Simmons wrote:
> Here are the latest updates to the framebuffer layer. Please test it outso
> I can push it as soon as possible to Linus.

The following comments are from a first review of sa1100fb.[ch] changes.

1. It would appear to break sa1100 inverse colourmap stuff.  There are LCD
   panels out there where it is a rather fundamental requirement to write
   the palette with "inverted" colourmap values.

2. I've no idea why you moved "lccr0" and "lccr3" in sa1100fb.h - this
   looks like noise to me.

3. I think you replaced "fbi" too many times:
	+/* Fake monspecs to fill in infonfo structure */

4. You're also merging in cpufreq changes from my tree in this patch;
   however I was going to send these to Linus along with the cpufreq
   submission so no problem.

5. I strongly disagree with your apparant decision to make the cpufreq
   part of the generic framebuffer core (by apparantly adding the notifier
   block to the core fb_info structure).  Firstly, you've broken sa1100fb.c
   by not including the relevant definition in fb_info (ok, so cpufreq
   stuff isn't in Linus' tree yet).  Secondly, it isn't something that all
   framebuffers require; its only required on SoC devices where the hardware
   designers have been stingy.  As such, we should NOT penalise the x86
   people by adding random useless garbage to structures that they're never
   going to use.

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

[Linux-fbdev-devel] [PATCH] Console/tty system patch. II

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

I fixed that bug with VT switching. Give the new patch a try so I can push
it to Linus. Thanks!!

BK:
	http://linuxconsole.bkbits.net:8080/dev

diff:
	http://www.transvirtual.com/~jsimmons/console.diff.gz

diffstat:

 arch/i386/kernel/apm.c         |    2
 arch/ppc/xmon/start.c          |    2
 arch/ppc64/xmon/start.c        |    2
 drivers/acpi/system.c          |    2
 drivers/char/console.c         |   82 ++--
 drivers/char/keyboard.c        |  781 +++++++++++++++++++++--------------------
 drivers/char/sysrq.c           |   46 +-
 drivers/char/tty_io.c          |   15
 include/linux/console_struct.h |    1
 include/linux/sysrq.h          |   13
 11 files changed, 487 insertions(+), 459 deletions(-)

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

[Linux-fbdev-devel] Re: [PATCH] New Console system BK

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

>  > Without the patch, I can hold down alt and hit F1, F2, F3, F4, then
>  > release the alt key and I will have switched to each of the VTs.
>  > With this patch, I have to press/release alt for each Fx key.
>
> Strange, that's a reoccurance of a bug that happened many moons ago
> circa 2.5.4-dj or so, which James then subsequently fixed. Seems he
> dropped a bugfix or two..

Ah. I was using the old patches. I will have to find the fix and put it
into the keyboard driver.

[Linux-fbdev-devel] Re: [PATCH] New Console system BK

[Dave J. <da...@su...>]

On Mon, Jul 01, 2002 at 08:11:28PM -0400, Skip Ford wrote:
 > James Simmons wrote:
 > > 
 > > Since 2.5.1 I have placed into the kernel part of the new console system
 > > code into the DJ tree. So it has been well tested. I was hoping to have
 > > all the keyboard devices ported over to the input api and the fbdev
 > > drivers over to the new api. Unfortunely due to time restraints this will
 > > not be the case. So here goes the first installment of the new console
 > > system. Please test it yourselves and I will push it to Linus soon.
 > > 
 > >  http://www.transvirtual.com/~jsimmons/console.diff.gz
 > 
 > With your patch, I have to release the alt key between Fx keys to change
 > VTs.  Is that intentional?
 > 
 > Without the patch, I can hold down alt and hit F1, F2, F3, F4, then
 > release the alt key and I will have switched to each of the VTs.
 > With this patch, I have to press/release alt for each Fx key.

Strange, that's a reoccurance of a bug that happened many moons ago
circa 2.5.4-dj or so, which James then subsequently fixed. Seems he
dropped a bugfix or two..

        Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [Linux-fbdev-devel] pm3fb driver is ok in 2.5.24

[Sven L. <lu...@la...>]

On Tue, Jul 02, 2002 at 10:36:39AM +0200, Romain Dolbeau wrote:
> Sven Luther wrote:
> 
> > > api. I'm going to removal the old fbgen code soon.
> > 
> > how soon, and is there documentation or sample code for the changed api
> > ?
> 
> According from a recent message by James Simmons on LKML:
> 
> >        Note I removed the old fbgen stuff so some drivers are going to
> > break. Well with time running out I need to push ahead. Sorry but I have
> > to choose.
> 
> So pm3fb won't work anymore I guess (due to the ultimate brokenness
> of linux on PowerPC I haven't yet ported pm3fb to the new API).

But it works fine right now on linus's 2.5.24, with the above sent
patch.

But it does need porting, i guess.

Friendly,

Sven Luther

[Linux-fbdev-devel] cfb_{copyarea,fillrect}()

[Geert U. <ge...@li...>]

	Hi,

This (untested) patch replaces the #if/#else/#endif clutter in cfb_fillrect()
with one #if/#else/#endif clause at the top of the file.

It also adds 64-bit support to cfb_copyarea().

Other comments/notes:

  - Shouldn't cfb_fillrect() use the pseudo_palette in DIRECTCOLOR mode?

  - I think the cfb_*() routines can easily be modified to work for bpp < 8,
    and for bpp == 24:
      o initialize src/dst indices to be bit indices instead of byte indices
      o remove shifts by 3
      o n is number of bits to copy/fill

  - I think that line length is not guaranteed to be a multiple of
    sizeof(unsigned long). Hence a different start/end mask per line is
    possible as well.

James: keep up the great work!

--- linux-2.5.24/drivers/video/cfbcopyarea.c	Fri Jun  7 11:06:41 2002
+++ linux-geert-2.5.24/drivers/video/cfbcopyarea.c	Wed Jun 26 04:04:09 2002
@@ -28,6 +28,14 @@
 #include <asm/io.h>
 #include <video/fbcon.h>
 
+#if BITS_PER_LONG == 32
+#define FB_READ		fb_readl
+#define FB_WRITE	fb_writel
+#else
+#define FB_READ		fb_readq
+#define FB_WRITE	fb_writeq
+#endif
+
 void cfb_copyarea(struct fb_info *p, struct fb_copyarea *area)
 {
 	int x2, y2, lineincr, shift, shift_right, shift_left, old_dx, old_dy;
@@ -137,19 +145,19 @@
 					dst = (unsigned long *) dst1;
 					src = (unsigned long *) src1;
 
-					last = (fb_readl(src) & start_mask);
+					last = (FB_READ(src) & start_mask);
 
 					if (shift > 0)
-						fb_writel(fb_readl(dst) | (last >> shift_right), dst);
+						FB_WRITE(FB_READ(dst) | (last >> shift_right), dst);
 					for (j = 0; j < n; j++) {
 						dst++;
-						tmp = fb_readl(src);
+						tmp = FB_READ(src);
 						src++;
-						fb_writel((last << shift_left) | (tmp >> shift_right), dst);
+						FB_WRITE((last << shift_left) | (tmp >> shift_right), dst);
 						last = tmp;
 						src++;
 					}
-					fb_writel(fb_readl(dst) | (last << shift_left), dst);
+					FB_WRITE(FB_READ(dst) | (last << shift_left), dst);
 					src1 += lineincr;
 					dst1 += lineincr;
 				} while (--height);
@@ -161,19 +169,19 @@
 					dst = (unsigned long *) dst1;
 					src = (unsigned long *) src1;
 
-					last = (fb_readl(src) & end_mask);
+					last = (FB_READ(src) & end_mask);
 
 					if (shift < 0)
-						fb_writel(fb_readl(dst) | (last >> shift_right), dst);
+						FB_WRITE(FB_READ(dst) | (last >> shift_right), dst);
 					for (j = 0; j < n; j++) {
 						dst--;
-						tmp = fb_readl(src);
+						tmp = FB_READ(src);
 						src--;
-						fb_writel((tmp << shift_left) | (last >> shift_right), dst);
+						FB_WRITE((tmp << shift_left) | (last >> shift_right), dst);
 						last = tmp;
 						src--;
 					}
-					fb_writel(fb_readl(dst) | (last >> shift_right), dst);
+					FB_WRITE(FB_READ(dst) | (last >> shift_right), dst);
 					src1 += lineincr;
 					dst1 += lineincr;
 				} while (--height);
@@ -187,16 +195,16 @@
 					src = (unsigned long *) (src1 - start_index);
 
 					if (start_mask)
-						fb_writel(fb_readl(src) | start_mask, dst);
+						FB_WRITE(FB_READ(src) | start_mask, dst);
 
 					for (j = 0; j < n; j++) {
-						fb_writel(fb_readl(src), dst);
+						FB_WRITE(FB_READ(src), dst);
 						dst++;
 						src++;
 					}
 
 					if (end_mask)
-						fb_writel(fb_readl(src) | end_mask, dst);
+						FB_WRITE(FB_READ(src) | end_mask, dst);
 					src1 += lineincr;
 					dst1 += lineincr;
 				} while (--height);
@@ -207,9 +215,9 @@
 					src = (unsigned long *) src1;
 
 					if (start_mask)
-						fb_writel(fb_readl(src) | start_mask, dst);
+						FB_WRITE(FB_READ(src) | start_mask, dst);
 					for (j = 0; j < n; j++) {
-						fb_writel(fb_readl(src), dst);
+						FB_WRITE(FB_READ(src), dst);
 						dst--;
 						src--;
 					}
--- linux-2.5.24/drivers/video/cfbfillrect.c	Thu May 30 08:10:36 2002
+++ linux-geert-2.5.24/drivers/video/cfbfillrect.c	Wed Jun 26 03:59:45 2002
@@ -22,6 +22,14 @@
 #include <asm/types.h>
 #include <video/fbcon.h>
 
+#if BITS_PER_LONG == 32
+#define FB_READ		fb_readl
+#define FB_WRITE	fb_writel
+#else
+#define FB_READ		fb_readq
+#define FB_WRITE	fb_writeq
+#endif
+
 void cfb_fillrect(struct fb_info *p, struct fb_fillrect *rect)
 {
 	unsigned long start_index, end_index, start_mask = 0, end_mask = 0;
@@ -93,33 +101,18 @@
 				dst = (unsigned long *) (dst1 - start_index);
 
 				if (start_mask) {
-#if BITS_PER_LONG == 32
-					fb_writel(fb_readl(dst) |
-						  start_mask, dst);
-#else
-					fb_writeq(fb_readq(dst) |
-						  start_mask, dst);
-#endif
+					FB_WRITE(FB_READ(dst) | start_mask,
+						 dst);
 					dst++;
 				}
 
 				for (i = 0; i < n; i++) {
-#if BITS_PER_LONG == 32
-					fb_writel(fg, dst);
-#else
-					fb_writeq(fg, dst);
-#endif
+					FB_WRITE(fg, dst);
 					dst++;
 				}
 
 				if (end_mask)
-#if BITS_PER_LONG == 32
-					fb_writel(fb_readl(dst) | end_mask,
-						  dst);
-#else
-					fb_writeq(fb_readq(dst) | end_mask,
-						  dst);
-#endif
+					FB_WRITE(FB_READ(dst) | end_mask, dst);
 				dst1 += linesize;
 			} while (--height);
 			break;
@@ -128,33 +121,18 @@
 				dst = (unsigned long *) (dst1 - start_index);
 
 				if (start_mask) {
-#if BITS_PER_LONG == 32
-					fb_writel(fb_readl(dst) ^
-						  start_mask, dst);
-#else
-					fb_writeq(fb_readq(dst) ^
-						  start_mask, dst);
-#endif
+					FB_WRITE(FB_READ(dst) ^ start_mask,
+						 dst);
 					dst++;
 				}
 
 				for (i = 0; i < n; i++) {
-#if BITS_PER_LONG == 32
-					fb_writel(fb_readl(dst) ^ fg, dst);
-#else
-					fb_writeq(fb_readq(dst) ^ fg, dst);
-#endif
+					FB_WRITE(FB_READ(dst) ^ fg, dst);
 					dst++;
 				}
 
 				if (end_mask) {
-#if BITS_PER_LONG == 32
-					fb_writel(fb_readl(dst) ^ end_mask,
-						  dst);
-#else
-					fb_writeq(fb_readq(dst) ^ end_mask,
-						  dst);
-#endif
+					FB_WRITE(FB_READ(dst) ^ end_mask, dst);
 				}
 				dst1 += linesize;
 			} while (--height);

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] [PATCH] fbdev updates.

[Jani M. <ja...@iv...>]

On Mon, 1 Jul 2002 10:48:41 -0700 (PDT)
James Simmons <jsi...@tr...> wrote:

> P.S
>        Note I removed the old fbgen stuff so some drivers are going to
> break. Well with time running out I need to push ahead. Sorry but I have
> to choose.

That's OK as long as we know that the drivers which are converted are 100% converted
and can be taken as an example.I prefer this approach instead of having to figure out
which incremental step towards the new api conversion was last taken and try to follow it.
So break the drivers and whatever else it takes so more people can confidently go on
and finally port their drivers.

Jani.