search for: vesafb

Hi All, I have looking for this for several days, maybe the usecase is wrong, but I have just configure my gentoo with xen as dom0, the vesafb works fine with the same kernel without xen, is it possible to use vesafb in dom0, and how can I configure it ? Waiting for your reply, and thanks a lot for your great help. --------------------------------- 雅虎邮箱传递新年祝福，个性贺卡送亲朋！ --0-1836158642-1204469256=:29641 Conten...

...gt; <andre.rodovalho at gmail.com> wrote: > >> > >> dmesg output: > >> > >> > >> > --------------------------------------------------------------------------------------------------------- > >> > >> > >> [ 1.018704] vesafb: mode is 640x480x32, linelength=2560, pages=0 > >> [ 1.018706] vesafb: scrolling: redraw > >> [ 1.018708] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 > >> [ 1.026887] vesafb: framebuffer at 0xfb000000, mapped to > >> 0xffffc90010e80000, using 1216k,...

It removes a hack from nouveau code which had to detect which region to pass to kick vesafb/efifb. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Eric Anholt <eric at anholt.net> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Thomas Hellstrom <thellstrom at vmware.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat....

Hello. Does anyone know why # CONFIG_FB_VESA is not set in kernel config? I find very useful having a large text console on servers (exp. without X running!). Now my setting vga=0x345 in grub.conf does not work anymore... Thanks! --Clorden

It simplifies nouveau code by removal of detection which region to pass to kick vesafb/efifb. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Eric Anholt <eric at anholt.net> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Thomas Hellstrom <thellstrom at vmware.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat....

fb_do_apertures_overlap is returning wrong value when one aperture is completely whithin the other. Add generic ranges_overlap macro (probably kernel.h candidate) and use it here. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat.com> Cc: Andrew Morton <akpm at linux-foundation.org> ---

...> > + if (rc && ((pci_dev->class >> 8) != PCI_CLASS_DISPLAY_VGA)) > > goto err_request_regions; > > > > if (force_legacy) { > > This is probably what you described as "the only concern? Ahem, no, forgot that one, but it is related. With vesafb using and registering the vga compat framebuffer bar pci_request_regions will not succeed. vesafb will be unregistered later on (this is what I was refering to) by the virtio-gpu driver. > If we only need to request specific > regions, I think we should do exactly that, requesting only part...

...> > + if (rc && ((pci_dev->class >> 8) != PCI_CLASS_DISPLAY_VGA)) > > goto err_request_regions; > > > > if (force_legacy) { > > This is probably what you described as "the only concern? Ahem, no, forgot that one, but it is related. With vesafb using and registering the vga compat framebuffer bar pci_request_regions will not succeed. vesafb will be unregistered later on (this is what I was refering to) by the virtio-gpu driver. > If we only need to request specific > regions, I think we should do exactly that, requesting only part...

...index 8e7dc1d..3943a00 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -317,6 +317,9 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t fb_width, info->fix.mmio_len = pci_resource_len(dev->pdev, 1); /* Set aperture base/size for vesafb takeover */ + + info->apertures = alloc_apertures(1); + #if defined(__i386__) || defined(__x86_64__) if (nouveau_fbcon_has_vesafb_or_efifb(dev)) { /* Some NVIDIA VBIOS' are stupid and decide to put the @@ -326,15 +329,15 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t fb_wi...

...VESA VGA - removing generic driver, - no problem when using a VGA mode (text only), this disregarding which X driver I use afterwards (I always start in console mode). But according to this page: http://nouveau.freedesktop.org/wiki/KernelModeSetting I thought nouveaufb shouldn't conflict with vesafb ? Am I wrong ? I tried with modules shipped in vanilla 2.6.33.1 as well as the last Nouveau kernel repository pulled from git: no luck in both cases. I know there are easy workarounds: either use "VGA=ask", "VGA=ext" or "VGA=normal" as a lilo.conf option or blacklist...

...t; Probably by that stage of the boot, framebuffer is already loaded. Use > vga=0x317 boot option to get a bigger resolution and more lines on it, > then send another pic. > > I hope it fits this time. If not, pick 0x31A, if your monitor allows. > > (kernel src, Documentation/fb/vesafb.txt) > | 640x480 800x600 1024x768 1280x1024 > ----+------------------------------------- > 256 | 0x301 0x303 0x305 0x307 > 32k | 0x310 0x313 0x316 0x319 > 64k | 0x311 0x314 0x317 0x31A > 16M | 0x312 0x315 0x318 0x31B > > Marcel...

http://bugs.freedesktop.org/show_bug.cgi?id=19620 Summary: At first start of X, secondary display doesn't come up properly. Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

Hello CentOS, I'm seeing this in the logwatch output. Anything I find on the net hasn't been definitive. The system is an x-less server. --------------------- Kernel Begin ------------------------ WARNING: Kernel Errors Present vesafb: probe of vesafb0 failed with error -6...: 6 Time(s) ---------------------- Kernel End ------------------------- -- Best regards, Mickael mailto:mike at kamloopsbc.com

...PLAY_VGA)) > > > goto err_request_regions; > > > > > > if (force_legacy) { > > > > This is probably what you described as "the only concern? > > Ahem, no, forgot that one, What does the concern refer to then? > but it is related. With vesafb using and > registering the vga compat framebuffer bar pci_request_regions will not > succeed. > > vesafb will be unregistered later on (this is what I was refering to) by > the virtio-gpu driver. > > > If we only need to request specific > > regions, I think we shou...

...PLAY_VGA)) > > > goto err_request_regions; > > > > > > if (force_legacy) { > > > > This is probably what you described as "the only concern? > > Ahem, no, forgot that one, What does the concern refer to then? > but it is related. With vesafb using and > registering the vga compat framebuffer bar pci_request_regions will not > succeed. > > vesafb will be unregistered later on (this is what I was refering to) by > the virtio-gpu driver. > > > If we only need to request specific > > regions, I think we shou...

...d, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API ksign: Installing public key data Loading keyring - Added public key 1D846148DE22BD48 - User ID: CentOS (Kernel Module GPG key) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 vesafb: framebuffer at 0xec000000, mapped to 0xd8080000, size 2560k vesafb: mode is 1280x1024x8, linelength=1280, pages=5 vesafb: protected mode interface info at c000:7e40 vesafb: scrolling: redraw vesafb: Pseudocolor: size=6:6:6:6, shift=0:0:0:0 Console: switching to colour frame buffer device 160x64 fb...

...94eb2..36d82e8 100644 --- a/drivers/virtio/virtio_pci_common.c +++ b/drivers/virtio/virtio_pci_common.c @@ -510,7 +510,12 @@ static int virtio_pci_probe(struct pci_dev *pci_dev, goto err_enable_device; rc = pci_request_regions(pci_dev, "virtio-pci"); - if (rc) + /* + * virtio-vga: vesafb/efifb might hold vga framebuffer + * resource, but don't fail on that, we'll kick out vesafb + * later on. + */ + if (rc && ((pci_dev->class >> 8) != PCI_CLASS_DISPLAY_VGA)) goto err_request_regions; if (force_legacy) { -- 1.8.3.1

...94eb2..36d82e8 100644 --- a/drivers/virtio/virtio_pci_common.c +++ b/drivers/virtio/virtio_pci_common.c @@ -510,7 +510,12 @@ static int virtio_pci_probe(struct pci_dev *pci_dev, goto err_enable_device; rc = pci_request_regions(pci_dev, "virtio-pci"); - if (rc) + /* + * virtio-vga: vesafb/efifb might hold vga framebuffer + * resource, but don't fail on that, we'll kick out vesafb + * later on. + */ + if (rc && ((pci_dev->class >> 8) != PCI_CLASS_DISPLAY_VGA)) goto err_request_regions; if (force_legacy) { -- 1.8.3.1

http://bugs.freedesktop.org/show_bug.cgi?id=15276 Summary: text rendering, PGRAPH_ERROR/ILLEGAL_MTHD/PROTECTION_FAULT spam in syslog Product: xorg Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component:

...ers/gpu/drm/nouveau/nouveau_drm.c index eb10c80ed853..e8560444ab57 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -697,7 +697,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev, nvkm_device_del(&device); /* Remove conflicting drivers (vesafb, efifb etc). */ - ret = remove_conflicting_pci_framebuffers(pdev, "nouveaufb"); + if (IS_ENABLED(CONFIG_FBDEV)) + ret = remove_conflicting_pci_framebuffers(pdev, "nouveaufb"); if (ret) return ret; -- 2.26.2