> > > Which is also why when > > drawing you need to use he screen width and not the window width to > > go > > to the next line. > > wrong. it's not the screen width, it's the screen-line pitch, or > stride, name it > as you wish. from the POV of the user of a framebuffer this has > little to do > with the buffer's visible geometry - horizontal dimension is one > thing, scanline > stride is another (the only thing that can be expected about it is > that it spans > _at_least_ framebuffer's number-of-columns). > That's what I was meaning actually, using "width" as the physical fb width, you can't change the "stride" of the framebuffer from the fake driver in that way. I think using an area and polling should the more flexible. François.