search for: fb_pan_display

...lanes at 7a2b46 > #6 [6beef760] vgdev_atomic_commit_tail at 7e9dbc > #7 [6beef790] commit_tail at 7a7126 > #8 [6beef7c0] drm_atomic_helper_commit at 7a73fe > #9 [6beef800] restore_fbdev_mode_atomic at 7aa38a > #10 [6beef8a0] drm_fb_helper_pan_display at 7ab7aa > #11 [6beef8f0] fb_pan_display at 74a248 > #12 [6beef928] bit_update_start at 7573c0 > #13 [6beef958] fbcon_switch at 7542b4 > #14 [6beefa50] redraw_screen at 77b2b8 > #15 [6beefaa0] csi_J at 77b476 > #16 [6beefad8] do_con_trol at 77ee12 > #17 [6beefb40] do_con_write at 77f80c > #18 [6beefc10] con_write at 7...

...LE_NAME), which is a comparison of omapdrmdrmfb == omapdrm and always fails. Fixing that, and applying this patch, things work fine (unaccelerated, of course). I did notice a single call to omap_fbdev_pan_display() when loading the drivers. This comes from fbcon_switch -> bit_update_start -> fb_pan_display. Maybe this is from the clearing you mention above? Reviewed-by: Tomi Valkeinen <tomi.valkeinen at ti.com> Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

...er systems, I'll take it up in Intel Graphics specific channels.? While the code is a mess right now, here is a link to the program: https://github.com/EchelonX-Ray/ttygraphics .? I'm just trying to learn about this and you really helped. On 7/5/20 7:17 PM, Ilia Mirkin wrote: > Check fb_pan_display in drivers/video/fbdev/core/fbmem.c for the > argument validation of the FBIOPAN_DISPLAY ioctl. > > CONFIG_FB_NVIDIA is a dedicated fbdev driver, not compatible with > nouveau (it takes over the relevant PCI device). It also won't support > your Pascal GPU, I believe -- I think i...

Well...it's been a bit of a mixed bag.? Setting drm_kms_helper.drm_fbdev_overalloc=200 set the vinfo.yres_virtual to 2160 as opposed to 1080 (My monitor vertical resolution)? This fixed the mmap() problem.? However, it only worked on my main workstation.? My laptop running Intel graphics wasn't affected by the change in kernel cmdline.? My workstation is a custom build from a few

Check fb_pan_display in drivers/video/fbdev/core/fbmem.c for the argument validation of the FBIOPAN_DISPLAY ioctl. CONFIG_FB_NVIDIA is a dedicated fbdev driver, not compatible with nouveau (it takes over the relevant PCI device). It also won't support your Pascal GPU, I believe -- I think it MIGHT support the Tesl...

...>dy, image->width, - image->height); -} - - -static struct fb_ops mgag200fb_ops = { - .owner = THIS_MODULE, - .fb_check_var = drm_fb_helper_check_var, - .fb_set_par = drm_fb_helper_set_par, - .fb_fillrect = mga_fillrect, - .fb_copyarea = mga_copyarea, - .fb_imageblit = mga_imageblit, - .fb_pan_display = drm_fb_helper_pan_display, - .fb_blank = drm_fb_helper_blank, - .fb_setcmap = drm_fb_helper_setcmap, -}; - -static int mgag200fb_create_object(struct mga_fbdev *afbdev, - const struct drm_mode_fb_cmd2 *mode_cmd, - struct drm_gem_object **gobj_p) -{ - struct drm_device *dev = afbdev-&g...

...image->dy, image->width, - image->height); -} - -static struct fb_ops astfb_ops = { - .owner = THIS_MODULE, - .fb_check_var = drm_fb_helper_check_var, - .fb_set_par = drm_fb_helper_set_par, - .fb_fillrect = ast_fillrect, - .fb_copyarea = ast_copyarea, - .fb_imageblit = ast_imageblit, - .fb_pan_display = drm_fb_helper_pan_display, - .fb_blank = drm_fb_helper_blank, - .fb_setcmap = drm_fb_helper_setcmap, -}; - -static int astfb_create_object(struct ast_fbdev *afbdev, - const struct drm_mode_fb_cmd2 *mode_cmd, - struct drm_gem_object **gobj_p) -{ - struct drm_device *dev = afbdev-...

DRM client buffers are permanently mapped throughout their lifetime. This prevents us from using generic framebuffer emulation for devices with small dedicated video memory, such as ast or mgag200. With fb buffers permanently mapped, such devices often won't have enougth space left to display other content (e.g., X11). This patch set introduces unmappable DRM client buffers for framebuffer

DRM client buffers are permanently mapped throughout their lifetime. This prevents us from using generic framebuffer emulation for devices with small dedicated video memory, such as ast or mgag200. With fb buffers permanently mapped, such devices often won't have enougth space left to display other content (e.g., X11). This patch set introduces unmappable DRM client buffers for framebuffer

DRM client buffers are permanently mapped throughout their lifetime. This prevents us from using generic framebuffer emulation for devices with small dedicated video memory, such as ast or mgag200. With fb buffers permanently mapped, such devices often won't have enough space left to display other content (e.g., X11). This patch set introduces unmappable DRM client buffers for framebuffer

DRM client buffers are permanently mapped throughout their lifetime. This prevents us from using generic framebuffer emulation for devices with small dedicated video memory, such as ast or mgag200. With fb buffers permanently mapped, such devices often won't have enough space left to display other content (e.g., X11). This patch set introduces unmappable DRM client buffers for framebuffer

...info); if (!ret && copy_to_user(argp, &var, sizeof(var))) ret = -EFAULT; @@ -1072,9 +1072,9 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd, return -EFAULT; if (!lock_fb_info(info)) return -ENODEV; - acquire_console_sem(); + console_lock(); ret = fb_pan_display(info, &var); - release_console_sem(); + console_unlock(); unlock_fb_info(info); if (ret == 0 && copy_to_user(argp, &var, sizeof(var))) return -EFAULT; @@ -1119,11 +1119,11 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd, case FBIOBLANK: if (!lock_f...

...info); if (!ret && copy_to_user(argp, &var, sizeof(var))) ret = -EFAULT; @@ -1072,9 +1072,9 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd, return -EFAULT; if (!lock_fb_info(info)) return -ENODEV; - acquire_console_sem(); + console_lock(); ret = fb_pan_display(info, &var); - release_console_sem(); + console_unlock(); unlock_fb_info(info); if (ret == 0 && copy_to_user(argp, &var, sizeof(var))) return -EFAULT; @@ -1119,11 +1119,11 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd, case FBIOBLANK: if (!lock_f...

...info); if (!ret && copy_to_user(argp, &var, sizeof(var))) ret = -EFAULT; @@ -1072,9 +1072,9 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd, return -EFAULT; if (!lock_fb_info(info)) return -ENODEV; - acquire_console_sem(); + console_lock(); ret = fb_pan_display(info, &var); - release_console_sem(); + console_unlock(); unlock_fb_info(info); if (ret == 0 && copy_to_user(argp, &var, sizeof(var))) return -EFAULT; @@ -1119,11 +1119,11 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd, case FBIOBLANK: if (!lock_f...

So ever since syzbot discovered fbcon, we have solid proof that it's full of bugs. And often the solution is to just delete code and remove features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code"). Now the problem is that most modern-ish drivers really only treat fbcon as an dumb kernel console until userspace takes over, and Oops printer for some emergencies. Looking at

...b_ops = { > - .owner = THIS_MODULE, > - .fb_check_var = drm_fb_helper_check_var, > - .fb_set_par = drm_fb_helper_set_par, > - .fb_fillrect = cirrus_fillrect, > - .fb_copyarea = cirrus_copyarea, > - .fb_imageblit = cirrus_imageblit, > - .fb_pan_display = drm_fb_helper_pan_display, > - .fb_blank = drm_fb_helper_blank, > - .fb_setcmap = drm_fb_helper_setcmap, > -}; > - > -static int cirrusfb_create_object(struct cirrus_fbdev *afbdev, > - const struct drm_mode_fb_cmd2 *mode_cmd, > -...

...image->width, - image->height); -} - - -static struct fb_ops cirrusfb_ops = { - .owner = THIS_MODULE, - .fb_check_var = drm_fb_helper_check_var, - .fb_set_par = drm_fb_helper_set_par, - .fb_fillrect = cirrus_fillrect, - .fb_copyarea = cirrus_copyarea, - .fb_imageblit = cirrus_imageblit, - .fb_pan_display = drm_fb_helper_pan_display, - .fb_blank = drm_fb_helper_blank, - .fb_setcmap = drm_fb_helper_setcmap, -}; - -static int cirrusfb_create_object(struct cirrus_fbdev *afbdev, - const struct drm_mode_fb_cmd2 *mode_cmd, - struct drm_gem_object **gobj_p) -{ - struct drm_device *dev = a...

...image->width, - image->height); -} - - -static struct fb_ops cirrusfb_ops = { - .owner = THIS_MODULE, - .fb_check_var = drm_fb_helper_check_var, - .fb_set_par = drm_fb_helper_set_par, - .fb_fillrect = cirrus_fillrect, - .fb_copyarea = cirrus_copyarea, - .fb_imageblit = cirrus_imageblit, - .fb_pan_display = drm_fb_helper_pan_display, - .fb_blank = drm_fb_helper_blank, - .fb_setcmap = drm_fb_helper_setcmap, -}; - -static int cirrusfb_create_object(struct cirrus_fbdev *afbdev, - const struct drm_mode_fb_cmd2 *mode_cmd, - struct drm_gem_object **gobj_p) -{ - struct drm_device *dev = a...

...image->width, - image->height); -} - - -static struct fb_ops cirrusfb_ops = { - .owner = THIS_MODULE, - .fb_check_var = drm_fb_helper_check_var, - .fb_set_par = drm_fb_helper_set_par, - .fb_fillrect = cirrus_fillrect, - .fb_copyarea = cirrus_copyarea, - .fb_imageblit = cirrus_imageblit, - .fb_pan_display = drm_fb_helper_pan_display, - .fb_blank = drm_fb_helper_blank, - .fb_setcmap = drm_fb_helper_setcmap, -}; - -static int cirrusfb_create_object(struct cirrus_fbdev *afbdev, - const struct drm_mode_fb_cmd2 *mode_cmd, - struct drm_gem_object **gobj_p) -{ - struct drm_device *dev = a...

...image->width, - image->height); -} - - -static struct fb_ops cirrusfb_ops = { - .owner = THIS_MODULE, - .fb_check_var = drm_fb_helper_check_var, - .fb_set_par = drm_fb_helper_set_par, - .fb_fillrect = cirrus_fillrect, - .fb_copyarea = cirrus_copyarea, - .fb_imageblit = cirrus_imageblit, - .fb_pan_display = drm_fb_helper_pan_display, - .fb_blank = drm_fb_helper_blank, - .fb_setcmap = drm_fb_helper_setcmap, -}; - -static int cirrusfb_create_object(struct cirrus_fbdev *afbdev, - const struct drm_mode_fb_cmd2 *mode_cmd, - struct drm_gem_object **gobj_p) -{ - struct drm_device *dev = a...