> Here's a diff to correct several small things that escaped through the
> cracks.
Ug. Now that a wider test base is being done and more drivers actually
compile we are going to see more cracks.
> 1. The YNOMOVE scrollmode for non-accelerated drivers is just very slow
> because of a lot of block moves (leads to slow and jerky scrolling in
> vesafb with ypanning enabled). Depending on var->accel_flags, set the
> scrollmode to either YREDRAW or YNOMOVE. For drivers with hardware
> acceleration, set var->accel_flags to nonzero for max speed.
Thanks. I have had several emails complementing the speed improvements.
Another speed boost will be a plus.
> 2. fb_pan_display() always returns an error. User apps will complain.
Fixed. Actually I used the following code.
int fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
{
int xoffset = var->xoffset;
int yoffset = var->yoffset;
int err;
if (xoffset < 0 || yoffset < 0 || info->fbops->fb_pan_display ||
xoffset + info->var.xres > info->var.xres_virtual ||
yoffset + info->var.yres > info->var.yres_virtual)
return -EINVAL;
if ((err = info->fbops->fb_pan_display(var, info)))
return err;
info->var.xoffset = var->xoffset;
info->var.yoffset = var->yoffset;
if (var->vmode & FB_VMODE_YWRAP)
instead. The reason is I didn't like the idea of xoffset and yoffset being
changed even if the hardware panning function failed. Comments?
> 3. case FBIO_GETCMAP in fb_ioctl does not return immediately. User
> apps will complain.
Fixed.
> 4. vgastate.c is not saving the correct blocks.
Fixed.
> 5. logo drawing for monochrome displays is just incorrect.(alterations
> were done by eyeballing only, no hardware for testing).
Will test on hgafb driver.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Dec 15 2002 - 22:00:20 EST