Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver

[Benjamin Herrenschmidt]

> Yes. I agree. The naming is crap. We're not blanking, we're changing 
> state.
> 
> But it's not a mode switch either - _sometimes_ it's a mode switch, but 
> sometimes the state change is that we're switching to another backing 
> store (ie a VC switch) but with the same mode.
> 
> So _logically_ the interface should be more of a "con_notify_change()"  
> one, with a bitmap of which states have changed (where "graphics vs text"
> is just one set of states - resultion is another, VC backing store is one,
> etc etc).
> 
> (I call it "notify_change()", because we have exactly that in VFS terms,
> where the inode change descriptor has an attribute table and a "valid"  
> bitmap).

Ok, if it's ok to delay it to 2.6.4, i'd prefer going all the way trough
calling it properly and passing the proper "state" flags instead of
hacking more on broken blank/unblank semantics. It can stay in -mm for
a while if we want enough testing.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/