similar to: [PATCH] drm/virtio: Allow userspace to mmap() framebuffer

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 Tesla generation (i.e. G80..GT21x) but definitely not anything newer. Most likely it

Oops, the FBIOPAN_DISPLAY ioctl error was a stupid mistake on mistake on my part.? Thanks for the info on where the validation code was.? Comparing against that made it easy to find the mistake.? It's working now, well...where I have been able to get over-allocation working!? Thanks for the help.? If I can't get the over-allocation to work on my other systems, I'll take it up in

On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: > Hi > > Am 09.04.19 um 09:12 schrieb kraxel at redhat.com: > > Hi, > > > >> If not for TTM, what would be the alternative? One VMA manager per > >> memory region per device? > > > > Depends pretty much on the device. > > > > The cirrus is a display device with

Hi list After I install xen4.0 in my debian squeezz,it added the following lines into /boot/grub/grub.cfg ### BEGIN /etc/grub.d/20_linux_xen ### menuentry ''Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN 4.0-amd64'' --class debian --class gnu-linux --class gnu --class os --class xen { insmod part_msdos insmod ext2 set

This patch replaces ast's framebuffer console with DRM's generic implememtation. All respective code is being removed from the driver. The console is set up with a shadow buffer. The actual buffer object is not permanently pinned in video ram, but just another buffer object that the driver moves in and out of vram as necessary. The driver's function ast_crtc_do_set_base() used to

On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Hi > > Am 15.04.19 um 17:54 schrieb Daniel Vetter: > > On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: > >> Hi > >> > >> Am 09.04.19 um 09:12 schrieb kraxel at redhat.com: > >>> Hi, > >>> > >>>> If not

On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Hi > > Am 15.04.19 um 17:54 schrieb Daniel Vetter: > > On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: > >> Hi > >> > >> Am 09.04.19 um 09:12 schrieb kraxel at redhat.com: > >>> Hi, > >>> > >>>> If not

At least sparc64 requires I/O-specific access to framebuffers. This patch updates the fbdev console accordingly. For drivers with direct access to the framebuffer memory, the callback functions in struct fb_ops test for the type of memory and call the rsp fb_sys_ of fb_cfb_ functions. For drivers that employ a shadow buffer, fbdev's blit function retrieves the framebuffer address as struct

At least sparc64 requires I/O-specific access to framebuffers. This patch updates the fbdev console accordingly. For drivers with direct access to the framebuffer memory, the callback functions in struct fb_ops test for the type of memory and call the rsp fb_sys_ of fb_cfb_ functions. Read and write operations are implemented internally by DRM's fbdev helper. For drivers that employ a shadow

At least sparc64 requires I/O-specific access to framebuffers. This patch updates the fbdev console accordingly. For drivers with direct access to the framebuffer memory, the callback functions in struct fb_ops test for the type of memory and call the rsp fb_sys_ of fb_cfb_ functions. Read and write operations are implemented internally by DRM's fbdev helper. For drivers that employ a shadow

Hi On Fri, 16 Oct 2020 12:58:54 +0200 Sam Ravnborg <sam at ravnborg.org> wrote: > Hi Thomas. > > On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote: > > At least sparc64 requires I/O-specific access to framebuffers. This > > patch updates the fbdev console accordingly. > > > > For drivers with direct access to the framebuffer memory, the

Hi On 22.10.20 10:05, Daniel Vetter wrote: > On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote: >> At least sparc64 requires I/O-specific access to framebuffers. This >> patch updates the fbdev console accordingly. >> >> For drivers with direct access to the framebuffer memory, the callback >> functions in struct fb_ops test for the type of memory

Hi On Fri, 16 Oct 2020 14:03:47 +0200 Sam Ravnborg <sam at ravnborg.org> wrote: > Hi Thomas. > > On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote: > > At least sparc64 requires I/O-specific access to framebuffers. This > > patch updates the fbdev console accordingly. > > > > For drivers with direct access to the framebuffer memory, the

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

Hi Thomas. On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote: > At least sparc64 requires I/O-specific access to framebuffers. This > patch updates the fbdev console accordingly. > > For drivers with direct access to the framebuffer memory, the callback > functions in struct fb_ops test for the type of memory and call the rsp > fb_sys_ of fb_cfb_ functions. >

Hi Thomas. On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote: > At least sparc64 requires I/O-specific access to framebuffers. This > patch updates the fbdev console accordingly. > > For drivers with direct access to the framebuffer memory, the callback > functions in struct fb_ops test for the type of memory and call the rsp > fb_sys_ of fb_cfb_ functions. Read

On Fri, Oct 2, 2020 at 8:05 PM Daniel Vetter <daniel at ffwll.ch> wrote: > > On Tue, Sep 29, 2020 at 05:14:36PM +0200, Thomas Zimmermann wrote: > > At least sparc64 requires I/O-specific access to framebuffers. This > > patch updates the fbdev console accordingly. > > > > For drivers with direct access to the framebuffer memory, the callback > > functions

Hi, > If not for TTM, what would be the alternative? One VMA manager per > memory region per device? Depends pretty much on the device. The cirrus is a display device with only 4 MB of vram. You can't fit much in there. A single 1024x768 @ 24bpp framebuffer needs more 50% of the video memory already. Which is why the cirrus driver (before the rewrite) had to migrate buffers from/to

Hi, > If not for TTM, what would be the alternative? One VMA manager per > memory region per device? Depends pretty much on the device. The cirrus is a display device with only 4 MB of vram. You can't fit much in there. A single 1024x768 @ 24bpp framebuffer needs more 50% of the video memory already. Which is why the cirrus driver (before the rewrite) had to migrate buffers from/to

Am 15.04.19 um 21:17 schrieb Daniel Vetter: > On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: >> Hi >> >> Am 15.04.19 um 17:54 schrieb Daniel Vetter: >>> On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: >>>> Hi >>>> >>>> Am 09.04.19 um 09:12 schrieb kraxel at redhat.com: