Re: [PATCH v3] drm/gma500: depend on framebuffer
On Thu, Apr 21, 2022 at 7:48 PM James Hilliard wrote: > > On Thu, Apr 21, 2022 at 8:20 AM Thomas Zimmermann wrote: > > > > Hi > > > > Am 21.04.22 um 14:54 schrieb Patrik Jakobsson: > > > On Thu, Apr 21, 2022 at 2:47 PM Javier Martinez Canillas > > > wrote: > > >> > > >> Hello Patrik, > > >> > > >> On 4/21/22 14:39, Patrik Jakobsson wrote: > > >>> On Thu, Apr 21, 2022 at 1:49 PM Thomas Zimmermann > > >>> wrote: > > > > Hi > > > > Am 09.04.22 um 06:23 schrieb James Hilliard: > > > Select the efi framebuffer if efi is enabled. > > > > > > This appears to be needed for video output to function correctly. > > > > > > Signed-off-by: James Hilliard > > > --- > > > Changes v2 -> v3: > > > - select EFI_FB instead of depending on it > > > Changes v1 -> v2: > > > - use depends instead of select > > > --- > > >drivers/gpu/drm/gma500/Kconfig | 2 ++ > > >1 file changed, 2 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/gma500/Kconfig > > > b/drivers/gpu/drm/gma500/Kconfig > > > index 0cff20265f97..a422fa84d53b 100644 > > > --- a/drivers/gpu/drm/gma500/Kconfig > > > +++ b/drivers/gpu/drm/gma500/Kconfig > > > @@ -2,11 +2,13 @@ > > >config DRM_GMA500 > > >tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" > > >depends on DRM && PCI && X86 && MMU > > > + depends on FB > > > > Why do we need FB here? Framebuffer support should be hidden by DRM's > > fbdev helpers. > > >>> > > >>> It is not needed but gives him video output since it enables the drm > > >>> fbdev emulation. > > >>> > > >> > > >> I'm not sure to understand this. Shouldn't depend on DRM_FBDEV_EMULATION > > >> then? > > > > It has to be selected separately in .config. > > > > James, make sure you have DRM_FBDEV_EMULATION enabled in your kernel's > > .config file if you want a console. however, Weston should work without > > it. How do you start weston without a console? > > Well it seems to be needed for weston to work over HDMI, I'm running > weston as a systemd service. > > > > > > > > > No, it shouldn't depend on any FBDEV stuff since it's not actually > > > required. It just happens to help in this case since weston + fbdev > > > backend works but not weston with drm backend (or whatever config > > > James have set). > > > > > >> > > >>> I looked some more at the logs and it seems weston doesn't work on his > > >>> system without the fbdev backend. So the question is why weston isn't > > >>> working without fbdev? Perhaps this is just a Weston configuration > > >>> issue? > > >>> > > >> > > >> But is weston using the fbdev emulated by DRM or the one registered by > > >> efifb? I thought that the latter from what was mentioned in this thread. > > > > > > It's using drm fbdev emulation with gma500 so EFIFB has nothing to do > > > with this. I believe it was just simply incorrectly reported. If I'm > > > correct then "depends on FB" is what makes video output work for > > > James. > > > > There's an fbdev backend for weston, but the provided logs don't look as > > if it's using this. Maybe the connector's modes are never probed > > correctly without fbdev. > > > > James, could you provide a logfile for weston? (i.e., 'weston > > --log=weston.txt'). > > Here's the log with output working over HDMI(DVI-D-1): > Date: 2022-04-21 UTC > [17:43:11.726] weston 10.0.0 >https://wayland.freedesktop.org >Bug reports to: > https://gitlab.freedesktop.org/wayland/weston/issues/ >Build: 10.0.0 > [17:43:11.727] Command line: /bin/weston > --config=/etc/xdg/weston/weston.ini --log=/srv/weston.txt -Swayland-1 > [17:43:11.727] OS: Linux, 5.17.3, #5 SMP PREEMPT Thu Apr 21 11:20:47 > MDT 2022, x86_64 > [17:43:11.727] Flight recorder: enabled > [17:43:11.727] Using config file '/etc/xdg/weston/weston.ini' > [17:43:11.727] Output repaint window is 7 ms maximum. > [17:43:11.727] Loading module '/usr/lib/libweston-10/drm-backend.so' > [17:43:11.743] initializing drm backend > [17:43:11.743] Trying logind launcher... > [17:43:11.743] logind: cannot find systemd session for uid: 0 -61 > [17:43:11.743] logind: cannot setup systemd-logind helper error: (No > data available), using legacy fallback > [17:43:11.744] Trying weston_launch launcher... > [17:43:11.744] could not get launcher fd from env > [17:43:11.744] Trying direct launcher... > [17:43:11.748] using /dev/dri/card0 > [17:43:11.748] DRM: does not support atomic modesetting > [17:43:11.748] DRM: does not support GBM modifiers > [17:43:11.748] DRM: supports picture aspect ratio > [17:43:11.765] event2 - Power Button: is tagged by udev as: Keyboard > [17:43:11.765] event2 - Power Button: device is a keyboard > [17:43:11.771] event3 - Video Bus: is tagged by udev as: Keyboard > [17:43:11.772] event3 - Video Bus: device is a keyboard > [17:43:11.777] event0 - Power Button: is tagged by udev as:
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Thu, Apr 21, 2022 at 1:23 PM Thomas Zimmermann wrote: > > Hi > > Am 21.04.22 um 20:22 schrieb Thomas Zimmermann: > > Hi > > > > Am 21.04.22 um 19:39 schrieb James Hilliard: > >> On Thu, Apr 21, 2022 at 8:22 AM Javier Martinez Canillas > >> wrote: > >>> > >>> On 4/21/22 14:54, Patrik Jakobsson wrote: > On Thu, Apr 21, 2022 at 2:47 PM Javier Martinez Canillas > wrote: > >>> > >>> [snip] > >>> > diff --git a/drivers/gpu/drm/gma500/Kconfig > b/drivers/gpu/drm/gma500/Kconfig > index 0cff20265f97..a422fa84d53b 100644 > --- a/drivers/gpu/drm/gma500/Kconfig > +++ b/drivers/gpu/drm/gma500/Kconfig > @@ -2,11 +2,13 @@ > config DRM_GMA500 > tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" > depends on DRM && PCI && X86 && MMU > + depends on FB > >>> > >>> Why do we need FB here? Framebuffer support should be hidden by > >>> DRM's > >>> fbdev helpers. > >> > >> It is not needed but gives him video output since it enables the drm > >> fbdev emulation. > >> > > > > I'm not sure to understand this. Shouldn't depend on > > DRM_FBDEV_EMULATION then? > > No, it shouldn't depend on any FBDEV stuff since it's not actually > required. It just happens to help in this case since weston + fbdev > backend works but not weston with drm backend (or whatever config > James have set). > >>> > >>> I see. Then the correct approach for them would be to just enable > >>> CONFIG_FB > >>> and DRM_FBDEV_EMULATION in their kernel config, rather than making > >>> this to > >>> depend on anything FB related as you said. > >> > >> Yeah, so it looks like CONFIG_FB_EFI is not needed but > >> CONFIG_DRM_FBDEV_EMULATION is, I think I just assumed efifb > >> was what was needed based on the kernel logs. > >> > >> This does not work: > >> CONFIG_FB enabled > >> CONFIG_DRM_FBDEV_EMULATION disabled > >> > >> This works: > >> CONFIG_FB enabled > >> CONFIG_DRM_FBDEV_EMULATION enabled > >> > >>> > > > > >> I looked some more at the logs and it seems weston doesn't work on > >> his > >> system without the fbdev backend. So the question is why weston isn't > >> working without fbdev? Perhaps this is just a Weston configuration > >> issue? > >> > > > > But is weston using the fbdev emulated by DRM or the one registered by > > efifb? I thought that the latter from what was mentioned in this > > thread. > > It's using drm fbdev emulation with gma500 so EFIFB has nothing to do > with this. I believe it was just simply incorrectly reported. If I'm > correct then "depends on FB" is what makes video output work for > James. > > >>> > >>> Got it. Thanks for the clarification. > >> > >> Here's my weston.ini: > >> [core] > >> shell=kiosk-shell.so > >> modules=systemd-notify.so > >> backend=drm-backend.so > >> idle-time=0 > >> require-input=false > >> use-pixman=true > >> > >> [shell] > >> locking=false > >> cursor-theme=Obsidian > >> panel-position=none > >> > >> [output] > >> name=DVI-D-1 > >> transform=rotate-270 > >> > >> [output] > >> name=DP-2 > >> mode=off > >> > >> [output] > >> name=LVDS-1 > >> mode=off > > > > You mentioned that you want to use HDMI, but it's not configured here. > > Is that intentionally? > > Nevermind. I just saw that DVI-D-1 is the HDMI port. (why?) Not sure why the HDMI output is named DVI-D-1 but that's what seems to configure it on this board. > > > > > Best regards > > Thomas > > > >> > >> [libinput] > >> touchscreen_calibrator=true > >> > >>> > >>> -- > >>> Best regards, > >>> > >>> Javier Martinez Canillas > >>> Linux Engineering > >>> Red Hat > >>> > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Ivo Totev
Re: [PATCH v3] drm/gma500: depend on framebuffer
Hi Am 21.04.22 um 20:22 schrieb Thomas Zimmermann: Hi Am 21.04.22 um 19:39 schrieb James Hilliard: On Thu, Apr 21, 2022 at 8:22 AM Javier Martinez Canillas wrote: On 4/21/22 14:54, Patrik Jakobsson wrote: On Thu, Apr 21, 2022 at 2:47 PM Javier Martinez Canillas wrote: [snip] diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig index 0cff20265f97..a422fa84d53b 100644 --- a/drivers/gpu/drm/gma500/Kconfig +++ b/drivers/gpu/drm/gma500/Kconfig @@ -2,11 +2,13 @@ config DRM_GMA500 tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" depends on DRM && PCI && X86 && MMU + depends on FB Why do we need FB here? Framebuffer support should be hidden by DRM's fbdev helpers. It is not needed but gives him video output since it enables the drm fbdev emulation. I'm not sure to understand this. Shouldn't depend on DRM_FBDEV_EMULATION then? No, it shouldn't depend on any FBDEV stuff since it's not actually required. It just happens to help in this case since weston + fbdev backend works but not weston with drm backend (or whatever config James have set). I see. Then the correct approach for them would be to just enable CONFIG_FB and DRM_FBDEV_EMULATION in their kernel config, rather than making this to depend on anything FB related as you said. Yeah, so it looks like CONFIG_FB_EFI is not needed but CONFIG_DRM_FBDEV_EMULATION is, I think I just assumed efifb was what was needed based on the kernel logs. This does not work: CONFIG_FB enabled CONFIG_DRM_FBDEV_EMULATION disabled This works: CONFIG_FB enabled CONFIG_DRM_FBDEV_EMULATION enabled I looked some more at the logs and it seems weston doesn't work on his system without the fbdev backend. So the question is why weston isn't working without fbdev? Perhaps this is just a Weston configuration issue? But is weston using the fbdev emulated by DRM or the one registered by efifb? I thought that the latter from what was mentioned in this thread. It's using drm fbdev emulation with gma500 so EFIFB has nothing to do with this. I believe it was just simply incorrectly reported. If I'm correct then "depends on FB" is what makes video output work for James. Got it. Thanks for the clarification. Here's my weston.ini: [core] shell=kiosk-shell.so modules=systemd-notify.so backend=drm-backend.so idle-time=0 require-input=false use-pixman=true [shell] locking=false cursor-theme=Obsidian panel-position=none [output] name=DVI-D-1 transform=rotate-270 [output] name=DP-2 mode=off [output] name=LVDS-1 mode=off You mentioned that you want to use HDMI, but it's not configured here. Is that intentionally? Nevermind. I just saw that DVI-D-1 is the HDMI port. (why?) Best regards Thomas [libinput] touchscreen_calibrator=true -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v3] drm/gma500: depend on framebuffer
Hi Am 21.04.22 um 19:39 schrieb James Hilliard: On Thu, Apr 21, 2022 at 8:22 AM Javier Martinez Canillas wrote: On 4/21/22 14:54, Patrik Jakobsson wrote: On Thu, Apr 21, 2022 at 2:47 PM Javier Martinez Canillas wrote: [snip] diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig index 0cff20265f97..a422fa84d53b 100644 --- a/drivers/gpu/drm/gma500/Kconfig +++ b/drivers/gpu/drm/gma500/Kconfig @@ -2,11 +2,13 @@ config DRM_GMA500 tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" depends on DRM && PCI && X86 && MMU + depends on FB Why do we need FB here? Framebuffer support should be hidden by DRM's fbdev helpers. It is not needed but gives him video output since it enables the drm fbdev emulation. I'm not sure to understand this. Shouldn't depend on DRM_FBDEV_EMULATION then? No, it shouldn't depend on any FBDEV stuff since it's not actually required. It just happens to help in this case since weston + fbdev backend works but not weston with drm backend (or whatever config James have set). I see. Then the correct approach for them would be to just enable CONFIG_FB and DRM_FBDEV_EMULATION in their kernel config, rather than making this to depend on anything FB related as you said. Yeah, so it looks like CONFIG_FB_EFI is not needed but CONFIG_DRM_FBDEV_EMULATION is, I think I just assumed efifb was what was needed based on the kernel logs. This does not work: CONFIG_FB enabled CONFIG_DRM_FBDEV_EMULATION disabled This works: CONFIG_FB enabled CONFIG_DRM_FBDEV_EMULATION enabled I looked some more at the logs and it seems weston doesn't work on his system without the fbdev backend. So the question is why weston isn't working without fbdev? Perhaps this is just a Weston configuration issue? But is weston using the fbdev emulated by DRM or the one registered by efifb? I thought that the latter from what was mentioned in this thread. It's using drm fbdev emulation with gma500 so EFIFB has nothing to do with this. I believe it was just simply incorrectly reported. If I'm correct then "depends on FB" is what makes video output work for James. Got it. Thanks for the clarification. Here's my weston.ini: [core] shell=kiosk-shell.so modules=systemd-notify.so backend=drm-backend.so idle-time=0 require-input=false use-pixman=true [shell] locking=false cursor-theme=Obsidian panel-position=none [output] name=DVI-D-1 transform=rotate-270 [output] name=DP-2 mode=off [output] name=LVDS-1 mode=off You mentioned that you want to use HDMI, but it's not configured here. Is that intentionally? Best regards Thomas [libinput] touchscreen_calibrator=true -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Thu, Apr 21, 2022 at 8:20 AM Thomas Zimmermann wrote: > > Hi > > Am 21.04.22 um 14:54 schrieb Patrik Jakobsson: > > On Thu, Apr 21, 2022 at 2:47 PM Javier Martinez Canillas > > wrote: > >> > >> Hello Patrik, > >> > >> On 4/21/22 14:39, Patrik Jakobsson wrote: > >>> On Thu, Apr 21, 2022 at 1:49 PM Thomas Zimmermann > >>> wrote: > > Hi > > Am 09.04.22 um 06:23 schrieb James Hilliard: > > Select the efi framebuffer if efi is enabled. > > > > This appears to be needed for video output to function correctly. > > > > Signed-off-by: James Hilliard > > --- > > Changes v2 -> v3: > > - select EFI_FB instead of depending on it > > Changes v1 -> v2: > > - use depends instead of select > > --- > >drivers/gpu/drm/gma500/Kconfig | 2 ++ > >1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/gma500/Kconfig > > b/drivers/gpu/drm/gma500/Kconfig > > index 0cff20265f97..a422fa84d53b 100644 > > --- a/drivers/gpu/drm/gma500/Kconfig > > +++ b/drivers/gpu/drm/gma500/Kconfig > > @@ -2,11 +2,13 @@ > >config DRM_GMA500 > >tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" > >depends on DRM && PCI && X86 && MMU > > + depends on FB > > Why do we need FB here? Framebuffer support should be hidden by DRM's > fbdev helpers. > >>> > >>> It is not needed but gives him video output since it enables the drm > >>> fbdev emulation. > >>> > >> > >> I'm not sure to understand this. Shouldn't depend on DRM_FBDEV_EMULATION > >> then? > > It has to be selected separately in .config. > > James, make sure you have DRM_FBDEV_EMULATION enabled in your kernel's > .config file if you want a console. however, Weston should work without > it. How do you start weston without a console? Well it seems to be needed for weston to work over HDMI, I'm running weston as a systemd service. > > > > > No, it shouldn't depend on any FBDEV stuff since it's not actually > > required. It just happens to help in this case since weston + fbdev > > backend works but not weston with drm backend (or whatever config > > James have set). > > > >> > >>> I looked some more at the logs and it seems weston doesn't work on his > >>> system without the fbdev backend. So the question is why weston isn't > >>> working without fbdev? Perhaps this is just a Weston configuration > >>> issue? > >>> > >> > >> But is weston using the fbdev emulated by DRM or the one registered by > >> efifb? I thought that the latter from what was mentioned in this thread. > > > > It's using drm fbdev emulation with gma500 so EFIFB has nothing to do > > with this. I believe it was just simply incorrectly reported. If I'm > > correct then "depends on FB" is what makes video output work for > > James. > > There's an fbdev backend for weston, but the provided logs don't look as > if it's using this. Maybe the connector's modes are never probed > correctly without fbdev. > > James, could you provide a logfile for weston? (i.e., 'weston > --log=weston.txt'). Here's the log with output working over HDMI(DVI-D-1): Date: 2022-04-21 UTC [17:43:11.726] weston 10.0.0 https://wayland.freedesktop.org Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/ Build: 10.0.0 [17:43:11.727] Command line: /bin/weston --config=/etc/xdg/weston/weston.ini --log=/srv/weston.txt -Swayland-1 [17:43:11.727] OS: Linux, 5.17.3, #5 SMP PREEMPT Thu Apr 21 11:20:47 MDT 2022, x86_64 [17:43:11.727] Flight recorder: enabled [17:43:11.727] Using config file '/etc/xdg/weston/weston.ini' [17:43:11.727] Output repaint window is 7 ms maximum. [17:43:11.727] Loading module '/usr/lib/libweston-10/drm-backend.so' [17:43:11.743] initializing drm backend [17:43:11.743] Trying logind launcher... [17:43:11.743] logind: cannot find systemd session for uid: 0 -61 [17:43:11.743] logind: cannot setup systemd-logind helper error: (No data available), using legacy fallback [17:43:11.744] Trying weston_launch launcher... [17:43:11.744] could not get launcher fd from env [17:43:11.744] Trying direct launcher... [17:43:11.748] using /dev/dri/card0 [17:43:11.748] DRM: does not support atomic modesetting [17:43:11.748] DRM: does not support GBM modifiers [17:43:11.748] DRM: supports picture aspect ratio [17:43:11.765] event2 - Power Button: is tagged by udev as: Keyboard [17:43:11.765] event2 - Power Button: device is a keyboard [17:43:11.771] event3 - Video Bus: is tagged by udev as: Keyboard [17:43:11.772] event3 - Video Bus: device is a keyboard [17:43:11.777] event0 - Power Button: is tagged by udev as: Keyboard [17:43:11.778] event0 - Power Button: device is a keyboard [17:43:11.785] event1 - Sleep Button: is tagged by udev as: Keyboard [17:43:11.787] event1 - Sleep Button: device is a keyboard [17:43:11.799] event4 - PiKVM Composite KVM Device: is tagged by udev as: Keyboard [17:43:11.799]
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Thu, Apr 21, 2022 at 8:22 AM Javier Martinez Canillas wrote: > > On 4/21/22 14:54, Patrik Jakobsson wrote: > > On Thu, Apr 21, 2022 at 2:47 PM Javier Martinez Canillas > > wrote: > > [snip] > > > diff --git a/drivers/gpu/drm/gma500/Kconfig > > b/drivers/gpu/drm/gma500/Kconfig > > index 0cff20265f97..a422fa84d53b 100644 > > --- a/drivers/gpu/drm/gma500/Kconfig > > +++ b/drivers/gpu/drm/gma500/Kconfig > > @@ -2,11 +2,13 @@ > > config DRM_GMA500 > > tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" > > depends on DRM && PCI && X86 && MMU > > + depends on FB > > Why do we need FB here? Framebuffer support should be hidden by DRM's > fbdev helpers. > >>> > >>> It is not needed but gives him video output since it enables the drm > >>> fbdev emulation. > >>> > >> > >> I'm not sure to understand this. Shouldn't depend on DRM_FBDEV_EMULATION > >> then? > > > > No, it shouldn't depend on any FBDEV stuff since it's not actually > > required. It just happens to help in this case since weston + fbdev > > backend works but not weston with drm backend (or whatever config > > James have set). > > I see. Then the correct approach for them would be to just enable CONFIG_FB > and DRM_FBDEV_EMULATION in their kernel config, rather than making this to > depend on anything FB related as you said. Yeah, so it looks like CONFIG_FB_EFI is not needed but CONFIG_DRM_FBDEV_EMULATION is, I think I just assumed efifb was what was needed based on the kernel logs. This does not work: CONFIG_FB enabled CONFIG_DRM_FBDEV_EMULATION disabled This works: CONFIG_FB enabled CONFIG_DRM_FBDEV_EMULATION enabled > > > > >> > >>> I looked some more at the logs and it seems weston doesn't work on his > >>> system without the fbdev backend. So the question is why weston isn't > >>> working without fbdev? Perhaps this is just a Weston configuration > >>> issue? > >>> > >> > >> But is weston using the fbdev emulated by DRM or the one registered by > >> efifb? I thought that the latter from what was mentioned in this thread. > > > > It's using drm fbdev emulation with gma500 so EFIFB has nothing to do > > with this. I believe it was just simply incorrectly reported. If I'm > > correct then "depends on FB" is what makes video output work for > > James. > > > > Got it. Thanks for the clarification. Here's my weston.ini: [core] shell=kiosk-shell.so modules=systemd-notify.so backend=drm-backend.so idle-time=0 require-input=false use-pixman=true [shell] locking=false cursor-theme=Obsidian panel-position=none [output] name=DVI-D-1 transform=rotate-270 [output] name=DP-2 mode=off [output] name=LVDS-1 mode=off [libinput] touchscreen_calibrator=true > > -- > Best regards, > > Javier Martinez Canillas > Linux Engineering > Red Hat >
Re: [PATCH v3] drm/gma500: depend on framebuffer
On 4/21/22 14:54, Patrik Jakobsson wrote: > On Thu, Apr 21, 2022 at 2:47 PM Javier Martinez Canillas > wrote: [snip] > diff --git a/drivers/gpu/drm/gma500/Kconfig > b/drivers/gpu/drm/gma500/Kconfig > index 0cff20265f97..a422fa84d53b 100644 > --- a/drivers/gpu/drm/gma500/Kconfig > +++ b/drivers/gpu/drm/gma500/Kconfig > @@ -2,11 +2,13 @@ > config DRM_GMA500 > tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" > depends on DRM && PCI && X86 && MMU > + depends on FB Why do we need FB here? Framebuffer support should be hidden by DRM's fbdev helpers. >>> >>> It is not needed but gives him video output since it enables the drm >>> fbdev emulation. >>> >> >> I'm not sure to understand this. Shouldn't depend on DRM_FBDEV_EMULATION >> then? > > No, it shouldn't depend on any FBDEV stuff since it's not actually > required. It just happens to help in this case since weston + fbdev > backend works but not weston with drm backend (or whatever config > James have set). I see. Then the correct approach for them would be to just enable CONFIG_FB and DRM_FBDEV_EMULATION in their kernel config, rather than making this to depend on anything FB related as you said. > >> >>> I looked some more at the logs and it seems weston doesn't work on his >>> system without the fbdev backend. So the question is why weston isn't >>> working without fbdev? Perhaps this is just a Weston configuration >>> issue? >>> >> >> But is weston using the fbdev emulated by DRM or the one registered by >> efifb? I thought that the latter from what was mentioned in this thread. > > It's using drm fbdev emulation with gma500 so EFIFB has nothing to do > with this. I believe it was just simply incorrectly reported. If I'm > correct then "depends on FB" is what makes video output work for > James. > Got it. Thanks for the clarification. -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v3] drm/gma500: depend on framebuffer
Hi Am 21.04.22 um 14:54 schrieb Patrik Jakobsson: On Thu, Apr 21, 2022 at 2:47 PM Javier Martinez Canillas wrote: Hello Patrik, On 4/21/22 14:39, Patrik Jakobsson wrote: On Thu, Apr 21, 2022 at 1:49 PM Thomas Zimmermann wrote: Hi Am 09.04.22 um 06:23 schrieb James Hilliard: Select the efi framebuffer if efi is enabled. This appears to be needed for video output to function correctly. Signed-off-by: James Hilliard --- Changes v2 -> v3: - select EFI_FB instead of depending on it Changes v1 -> v2: - use depends instead of select --- drivers/gpu/drm/gma500/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig index 0cff20265f97..a422fa84d53b 100644 --- a/drivers/gpu/drm/gma500/Kconfig +++ b/drivers/gpu/drm/gma500/Kconfig @@ -2,11 +2,13 @@ config DRM_GMA500 tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" depends on DRM && PCI && X86 && MMU + depends on FB Why do we need FB here? Framebuffer support should be hidden by DRM's fbdev helpers. It is not needed but gives him video output since it enables the drm fbdev emulation. I'm not sure to understand this. Shouldn't depend on DRM_FBDEV_EMULATION then? It has to be selected separately in .config. James, make sure you have DRM_FBDEV_EMULATION enabled in your kernel's .config file if you want a console. however, Weston should work without it. How do you start weston without a console? No, it shouldn't depend on any FBDEV stuff since it's not actually required. It just happens to help in this case since weston + fbdev backend works but not weston with drm backend (or whatever config James have set). I looked some more at the logs and it seems weston doesn't work on his system without the fbdev backend. So the question is why weston isn't working without fbdev? Perhaps this is just a Weston configuration issue? But is weston using the fbdev emulated by DRM or the one registered by efifb? I thought that the latter from what was mentioned in this thread. It's using drm fbdev emulation with gma500 so EFIFB has nothing to do with this. I believe it was just simply incorrectly reported. If I'm correct then "depends on FB" is what makes video output work for James. There's an fbdev backend for weston, but the provided logs don't look as if it's using this. Maybe the connector's modes are never probed correctly without fbdev. James, could you provide a logfile for weston? (i.e., 'weston --log=weston.txt'). Best regards Thomas -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Thu, Apr 21, 2022 at 2:47 PM Javier Martinez Canillas wrote: > > Hello Patrik, > > On 4/21/22 14:39, Patrik Jakobsson wrote: > > On Thu, Apr 21, 2022 at 1:49 PM Thomas Zimmermann > > wrote: > >> > >> Hi > >> > >> Am 09.04.22 um 06:23 schrieb James Hilliard: > >>> Select the efi framebuffer if efi is enabled. > >>> > >>> This appears to be needed for video output to function correctly. > >>> > >>> Signed-off-by: James Hilliard > >>> --- > >>> Changes v2 -> v3: > >>>- select EFI_FB instead of depending on it > >>> Changes v1 -> v2: > >>>- use depends instead of select > >>> --- > >>> drivers/gpu/drm/gma500/Kconfig | 2 ++ > >>> 1 file changed, 2 insertions(+) > >>> > >>> diff --git a/drivers/gpu/drm/gma500/Kconfig > >>> b/drivers/gpu/drm/gma500/Kconfig > >>> index 0cff20265f97..a422fa84d53b 100644 > >>> --- a/drivers/gpu/drm/gma500/Kconfig > >>> +++ b/drivers/gpu/drm/gma500/Kconfig > >>> @@ -2,11 +2,13 @@ > >>> config DRM_GMA500 > >>> tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" > >>> depends on DRM && PCI && X86 && MMU > >>> + depends on FB > >> > >> Why do we need FB here? Framebuffer support should be hidden by DRM's > >> fbdev helpers. > > > > It is not needed but gives him video output since it enables the drm > > fbdev emulation. > > > > I'm not sure to understand this. Shouldn't depend on DRM_FBDEV_EMULATION then? No, it shouldn't depend on any FBDEV stuff since it's not actually required. It just happens to help in this case since weston + fbdev backend works but not weston with drm backend (or whatever config James have set). > > > I looked some more at the logs and it seems weston doesn't work on his > > system without the fbdev backend. So the question is why weston isn't > > working without fbdev? Perhaps this is just a Weston configuration > > issue? > > > > But is weston using the fbdev emulated by DRM or the one registered by > efifb? I thought that the latter from what was mentioned in this thread. It's using drm fbdev emulation with gma500 so EFIFB has nothing to do with this. I believe it was just simply incorrectly reported. If I'm correct then "depends on FB" is what makes video output work for James. > > -- > Best regards, > > Javier Martinez Canillas > Linux Engineering > Red Hat >
Re: [PATCH v3] drm/gma500: depend on framebuffer
Hello Patrik, On 4/21/22 14:39, Patrik Jakobsson wrote: > On Thu, Apr 21, 2022 at 1:49 PM Thomas Zimmermann wrote: >> >> Hi >> >> Am 09.04.22 um 06:23 schrieb James Hilliard: >>> Select the efi framebuffer if efi is enabled. >>> >>> This appears to be needed for video output to function correctly. >>> >>> Signed-off-by: James Hilliard >>> --- >>> Changes v2 -> v3: >>>- select EFI_FB instead of depending on it >>> Changes v1 -> v2: >>>- use depends instead of select >>> --- >>> drivers/gpu/drm/gma500/Kconfig | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig >>> index 0cff20265f97..a422fa84d53b 100644 >>> --- a/drivers/gpu/drm/gma500/Kconfig >>> +++ b/drivers/gpu/drm/gma500/Kconfig >>> @@ -2,11 +2,13 @@ >>> config DRM_GMA500 >>> tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" >>> depends on DRM && PCI && X86 && MMU >>> + depends on FB >> >> Why do we need FB here? Framebuffer support should be hidden by DRM's >> fbdev helpers. > > It is not needed but gives him video output since it enables the drm > fbdev emulation. > I'm not sure to understand this. Shouldn't depend on DRM_FBDEV_EMULATION then? > I looked some more at the logs and it seems weston doesn't work on his > system without the fbdev backend. So the question is why weston isn't > working without fbdev? Perhaps this is just a Weston configuration > issue? > But is weston using the fbdev emulated by DRM or the one registered by efifb? I thought that the latter from what was mentioned in this thread. -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Thu, Apr 21, 2022 at 1:49 PM Thomas Zimmermann wrote: > > Hi > > Am 09.04.22 um 06:23 schrieb James Hilliard: > > Select the efi framebuffer if efi is enabled. > > > > This appears to be needed for video output to function correctly. > > > > Signed-off-by: James Hilliard > > --- > > Changes v2 -> v3: > >- select EFI_FB instead of depending on it > > Changes v1 -> v2: > >- use depends instead of select > > --- > > drivers/gpu/drm/gma500/Kconfig | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig > > index 0cff20265f97..a422fa84d53b 100644 > > --- a/drivers/gpu/drm/gma500/Kconfig > > +++ b/drivers/gpu/drm/gma500/Kconfig > > @@ -2,11 +2,13 @@ > > config DRM_GMA500 > > tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" > > depends on DRM && PCI && X86 && MMU > > + depends on FB > > Why do we need FB here? Framebuffer support should be hidden by DRM's > fbdev helpers. It is not needed but gives him video output since it enables the drm fbdev emulation. I looked some more at the logs and it seems weston doesn't work on his system without the fbdev backend. So the question is why weston isn't working without fbdev? Perhaps this is just a Weston configuration issue?
Re: [PATCH v3] drm/gma500: depend on framebuffer
Hi Am 09.04.22 um 06:23 schrieb James Hilliard: Select the efi framebuffer if efi is enabled. This appears to be needed for video output to function correctly. Signed-off-by: James Hilliard --- Changes v2 -> v3: - select EFI_FB instead of depending on it Changes v1 -> v2: - use depends instead of select --- drivers/gpu/drm/gma500/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig index 0cff20265f97..a422fa84d53b 100644 --- a/drivers/gpu/drm/gma500/Kconfig +++ b/drivers/gpu/drm/gma500/Kconfig @@ -2,11 +2,13 @@ config DRM_GMA500 tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" depends on DRM && PCI && X86 && MMU + depends on FB Why do we need FB here? Framebuffer support should be hidden by DRM's fbdev helpers. Best regards Thomas select DRM_KMS_HELPER # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915 select ACPI_VIDEO if ACPI select BACKLIGHT_CLASS_DEVICE if ACPI select INPUT if ACPI + select FB_EFI if EFI help Say yes for an experimental 2D KMS framebuffer driver for the Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Wed, Apr 20, 2022 at 1:42 AM James Hilliard wrote: > > On Tue, Apr 12, 2022 at 3:30 AM Patrik Jakobsson > wrote: > > > > On Tue, Apr 12, 2022 at 3:48 AM James Hilliard > > wrote: > > > > > > On Mon, Apr 11, 2022 at 3:27 AM Patrik Jakobsson > > > wrote: > > > > > > > > On Sun, Apr 10, 2022 at 10:05 PM James Hilliard > > > > wrote: > > > > > > > > > > On Sun, Apr 10, 2022 at 1:52 PM Patrik Jakobsson > > > > > wrote: > > > > > > > > > > > > On Sun, Apr 10, 2022 at 9:40 PM James Hilliard > > > > > > wrote: > > > > > > > > > > > > > > On Sun, Apr 10, 2022 at 1:36 PM Patrik Jakobsson > > > > > > > wrote: > > > > > > > > > > > > > > > > On Sat, Apr 9, 2022 at 6:23 AM James Hilliard > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Select the efi framebuffer if efi is enabled. > > > > > > > > > > > > > > > > > > This appears to be needed for video output to function > > > > > > > > > correctly. > > > > > > > > > > > > > > > > > > Signed-off-by: James Hilliard > > > > > > > > > > > > > > > > Hi James, > > > > > > > > EFI_FB is its own driver and not needed by gma500 to drive its > > > > > > > > hardware. What makes you think it's required? > > > > > > > > > > > > > > I wasn't getting any HDMI video output without it enabled for > > > > > > > some reason, > > > > > > > I assume it is doing some sort of initialization needed by gma500 > > > > > > > during startup. > > > > > > > > > > > > Then it sounds like you might just be using EFI_FB and not gma500. > > > > > > Can > > > > > > you provide the kernel log with drm.debug=0x1f set on kernel > > > > > > command-line. > > > > > > > > > > Seems efifb loads first and then hands off to gma500 > > > > > > > > That is how it normally works but efifb shouldn't change the state of > > > > the currently set mode so shouldn't affect gma500. > > > > From the logs I can see that you have LVDS (internal panel), HDMI and > > > > DP (3 displays in total) connected. This sounds wrong. Your version of > > > > gma500 (Cedarview) doesn't support more than 2 crtcs/pipes. This might > > > > be a problem. > > > > > > Yeah, there's a bug there with the connector status, only DVI-D-1 is > > > actually > > > connected, I have DP-2 and LVDS-1 turned off in weston. > > > > Ok, but are the connectors physically connected to anything? > > There is one HDMI cable physically connected to the board > > > Regardless of what you do in Weston, the connectors shouldn't be > > getting modes if they aren't used. > > Yeah, it seems there's a bug there, not sure if that's related to the > output failure when efifb isn't available. > > > LVDS might be from VBIOS but I'm > > not sure where the DP modes come from. It would help if you also > > provide kernel logs with drm.debug=0x1f when the outputs doesn't work > > so I have something to compare with. > > Log with efifb/fb not enabled in kernel build which causes no > HDMI output: After examining the logs I cannot see anything that stands out except for fbdev emulation not being enabled. Are you sure you just don't need to compile your kernel with FB support (CONFIG_FB)? If you are running weston on the fbdev backend then you would obviously not get any output if FB is not compiled into the kernel.
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Tue, Apr 12, 2022 at 3:30 AM Patrik Jakobsson wrote: > > On Tue, Apr 12, 2022 at 3:48 AM James Hilliard > wrote: > > > > On Mon, Apr 11, 2022 at 3:27 AM Patrik Jakobsson > > wrote: > > > > > > On Sun, Apr 10, 2022 at 10:05 PM James Hilliard > > > wrote: > > > > > > > > On Sun, Apr 10, 2022 at 1:52 PM Patrik Jakobsson > > > > wrote: > > > > > > > > > > On Sun, Apr 10, 2022 at 9:40 PM James Hilliard > > > > > wrote: > > > > > > > > > > > > On Sun, Apr 10, 2022 at 1:36 PM Patrik Jakobsson > > > > > > wrote: > > > > > > > > > > > > > > On Sat, Apr 9, 2022 at 6:23 AM James Hilliard > > > > > > > wrote: > > > > > > > > > > > > > > > > Select the efi framebuffer if efi is enabled. > > > > > > > > > > > > > > > > This appears to be needed for video output to function > > > > > > > > correctly. > > > > > > > > > > > > > > > > Signed-off-by: James Hilliard > > > > > > > > > > > > > > Hi James, > > > > > > > EFI_FB is its own driver and not needed by gma500 to drive its > > > > > > > hardware. What makes you think it's required? > > > > > > > > > > > > I wasn't getting any HDMI video output without it enabled for some > > > > > > reason, > > > > > > I assume it is doing some sort of initialization needed by gma500 > > > > > > during startup. > > > > > > > > > > Then it sounds like you might just be using EFI_FB and not gma500. Can > > > > > you provide the kernel log with drm.debug=0x1f set on kernel > > > > > command-line. > > > > > > > > Seems efifb loads first and then hands off to gma500 > > > > > > That is how it normally works but efifb shouldn't change the state of > > > the currently set mode so shouldn't affect gma500. > > > From the logs I can see that you have LVDS (internal panel), HDMI and > > > DP (3 displays in total) connected. This sounds wrong. Your version of > > > gma500 (Cedarview) doesn't support more than 2 crtcs/pipes. This might > > > be a problem. > > > > Yeah, there's a bug there with the connector status, only DVI-D-1 is > > actually > > connected, I have DP-2 and LVDS-1 turned off in weston. > > Ok, but are the connectors physically connected to anything? There is one HDMI cable physically connected to the board > Regardless of what you do in Weston, the connectors shouldn't be > getting modes if they aren't used. Yeah, it seems there's a bug there, not sure if that's related to the output failure when efifb isn't available. > LVDS might be from VBIOS but I'm > not sure where the DP modes come from. It would help if you also > provide kernel logs with drm.debug=0x1f when the outputs doesn't work > so I have something to compare with. Log with efifb/fb not enabled in kernel build which causes no HDMI output: [0.00] Linux version 5.17.3 (buildroot@james-x399) (x86_64-buildroot-linux-gnu-gcc.br_real (Buildroot 2022.02-533-g95bc9df0b3) 10.3.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP PREEMPT Tue Apr 19 15:14:53 MDT 2022 [0.00] Command line: root=PARTUUID=dea0d091-16af-704f-977c-1a5475cf261c rootwait drm.debug=0x1f console=tty1 [0.00] Disabled fast string operations [0.00] x86/fpu: x87 FPU will use FXSAVE [0.00] signal: max sigframe size: 1440 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009] usable [0.00] BIOS-e820: [mem 0x000a-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcf32cfff] usable [0.00] BIOS-e820: [mem 0xcf32d000-0xcf374fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcf375000-0xcf385fff] reserved [0.00] BIOS-e820: [mem 0xcf386000-0xcf38dfff] ACPI data [0.00] BIOS-e820: [mem 0xcf38e000-0xcf3b5fff] reserved [0.00] BIOS-e820: [mem 0xcf3b6000-0xcf3b6fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcf3b7000-0xcf3c6fff] reserved [0.00] BIOS-e820: [mem 0xcf3c7000-0xcf3d2fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcf3d3000-0xcf3f7fff] reserved [0.00] BIOS-e820: [mem 0xcf3f8000-0xcf43afff] ACPI NVS [0.00] BIOS-e820: [mem 0xcf43b000-0xcf5bafff] usable [0.00] BIOS-e820: [mem 0xcf5bb000-0xcf6e6fff] reserved [0.00] BIOS-e820: [mem 0xcf6e7000-0xcf6e] usable [0.00] BIOS-e820: [mem 0xcf6f-0xcfff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Tue, Apr 12, 2022 at 3:48 AM James Hilliard wrote: > > On Mon, Apr 11, 2022 at 3:27 AM Patrik Jakobsson > wrote: > > > > On Sun, Apr 10, 2022 at 10:05 PM James Hilliard > > wrote: > > > > > > On Sun, Apr 10, 2022 at 1:52 PM Patrik Jakobsson > > > wrote: > > > > > > > > On Sun, Apr 10, 2022 at 9:40 PM James Hilliard > > > > wrote: > > > > > > > > > > On Sun, Apr 10, 2022 at 1:36 PM Patrik Jakobsson > > > > > wrote: > > > > > > > > > > > > On Sat, Apr 9, 2022 at 6:23 AM James Hilliard > > > > > > wrote: > > > > > > > > > > > > > > Select the efi framebuffer if efi is enabled. > > > > > > > > > > > > > > This appears to be needed for video output to function correctly. > > > > > > > > > > > > > > Signed-off-by: James Hilliard > > > > > > > > > > > > Hi James, > > > > > > EFI_FB is its own driver and not needed by gma500 to drive its > > > > > > hardware. What makes you think it's required? > > > > > > > > > > I wasn't getting any HDMI video output without it enabled for some > > > > > reason, > > > > > I assume it is doing some sort of initialization needed by gma500 > > > > > during startup. > > > > > > > > Then it sounds like you might just be using EFI_FB and not gma500. Can > > > > you provide the kernel log with drm.debug=0x1f set on kernel > > > > command-line. > > > > > > Seems efifb loads first and then hands off to gma500 > > > > That is how it normally works but efifb shouldn't change the state of > > the currently set mode so shouldn't affect gma500. > > From the logs I can see that you have LVDS (internal panel), HDMI and > > DP (3 displays in total) connected. This sounds wrong. Your version of > > gma500 (Cedarview) doesn't support more than 2 crtcs/pipes. This might > > be a problem. > > Yeah, there's a bug there with the connector status, only DVI-D-1 is actually > connected, I have DP-2 and LVDS-1 turned off in weston. Ok, but are the connectors physically connected to anything? Regardless of what you do in Weston, the connectors shouldn't be getting modes if they aren't used. LVDS might be from VBIOS but I'm not sure where the DP modes come from. It would help if you also provide kernel logs with drm.debug=0x1f when the outputs doesn't work so I have something to compare with.
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Mon, Apr 11, 2022 at 3:27 AM Patrik Jakobsson wrote: > > On Sun, Apr 10, 2022 at 10:05 PM James Hilliard > wrote: > > > > On Sun, Apr 10, 2022 at 1:52 PM Patrik Jakobsson > > wrote: > > > > > > On Sun, Apr 10, 2022 at 9:40 PM James Hilliard > > > wrote: > > > > > > > > On Sun, Apr 10, 2022 at 1:36 PM Patrik Jakobsson > > > > wrote: > > > > > > > > > > On Sat, Apr 9, 2022 at 6:23 AM James Hilliard > > > > > wrote: > > > > > > > > > > > > Select the efi framebuffer if efi is enabled. > > > > > > > > > > > > This appears to be needed for video output to function correctly. > > > > > > > > > > > > Signed-off-by: James Hilliard > > > > > > > > > > Hi James, > > > > > EFI_FB is its own driver and not needed by gma500 to drive its > > > > > hardware. What makes you think it's required? > > > > > > > > I wasn't getting any HDMI video output without it enabled for some > > > > reason, > > > > I assume it is doing some sort of initialization needed by gma500 > > > > during startup. > > > > > > Then it sounds like you might just be using EFI_FB and not gma500. Can > > > you provide the kernel log with drm.debug=0x1f set on kernel > > > command-line. > > > > Seems efifb loads first and then hands off to gma500 > > That is how it normally works but efifb shouldn't change the state of > the currently set mode so shouldn't affect gma500. > From the logs I can see that you have LVDS (internal panel), HDMI and > DP (3 displays in total) connected. This sounds wrong. Your version of > gma500 (Cedarview) doesn't support more than 2 crtcs/pipes. This might > be a problem. Yeah, there's a bug there with the connector status, only DVI-D-1 is actually connected, I have DP-2 and LVDS-1 turned off in weston.
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Sun, Apr 10, 2022 at 10:05 PM James Hilliard wrote: > > On Sun, Apr 10, 2022 at 1:52 PM Patrik Jakobsson > wrote: > > > > On Sun, Apr 10, 2022 at 9:40 PM James Hilliard > > wrote: > > > > > > On Sun, Apr 10, 2022 at 1:36 PM Patrik Jakobsson > > > wrote: > > > > > > > > On Sat, Apr 9, 2022 at 6:23 AM James Hilliard > > > > wrote: > > > > > > > > > > Select the efi framebuffer if efi is enabled. > > > > > > > > > > This appears to be needed for video output to function correctly. > > > > > > > > > > Signed-off-by: James Hilliard > > > > > > > > Hi James, > > > > EFI_FB is its own driver and not needed by gma500 to drive its > > > > hardware. What makes you think it's required? > > > > > > I wasn't getting any HDMI video output without it enabled for some reason, > > > I assume it is doing some sort of initialization needed by gma500 > > > during startup. > > > > Then it sounds like you might just be using EFI_FB and not gma500. Can > > you provide the kernel log with drm.debug=0x1f set on kernel > > command-line. > > Seems efifb loads first and then hands off to gma500 That is how it normally works but efifb shouldn't change the state of the currently set mode so shouldn't affect gma500. >From the logs I can see that you have LVDS (internal panel), HDMI and DP (3 displays in total) connected. This sounds wrong. Your version of gma500 (Cedarview) doesn't support more than 2 crtcs/pipes. This might be a problem.
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Sun, Apr 10, 2022 at 1:52 PM Patrik Jakobsson wrote: > > On Sun, Apr 10, 2022 at 9:40 PM James Hilliard > wrote: > > > > On Sun, Apr 10, 2022 at 1:36 PM Patrik Jakobsson > > wrote: > > > > > > On Sat, Apr 9, 2022 at 6:23 AM James Hilliard > > > wrote: > > > > > > > > Select the efi framebuffer if efi is enabled. > > > > > > > > This appears to be needed for video output to function correctly. > > > > > > > > Signed-off-by: James Hilliard > > > > > > Hi James, > > > EFI_FB is its own driver and not needed by gma500 to drive its > > > hardware. What makes you think it's required? > > > > I wasn't getting any HDMI video output without it enabled for some reason, > > I assume it is doing some sort of initialization needed by gma500 > > during startup. > > Then it sounds like you might just be using EFI_FB and not gma500. Can > you provide the kernel log with drm.debug=0x1f set on kernel > command-line. Seems efifb loads first and then hands off to gma500 [0.00] Linux version 5.17.1 (buildroot@james-x399) (x86_64-buildroot-linux-gnu-gcc.br_real (Buildroot 2022.02-439-ge14798fa29) 10.3.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP PREEMPT Thu Apr 7 00:14:30 MDT 2022 [0.00] Command line: root=PARTUUID=9bc7b8cb-3b3a-994c-9dca-0abbc5055e4d rootwait drm.debug=0x1f console=tty1 [0.00] Disabled fast string operations [0.00] x86/fpu: x87 FPU will use FXSAVE [0.00] signal: max sigframe size: 1440 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009] usable [0.00] BIOS-e820: [mem 0x000a-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcf32cfff] usable [0.00] BIOS-e820: [mem 0xcf32d000-0xcf374fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcf375000-0xcf385fff] reserved [0.00] BIOS-e820: [mem 0xcf386000-0xcf38dfff] ACPI data [0.00] BIOS-e820: [mem 0xcf38e000-0xcf3b5fff] reserved [0.00] BIOS-e820: [mem 0xcf3b6000-0xcf3b6fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcf3b7000-0xcf3c6fff] reserved [0.00] BIOS-e820: [mem 0xcf3c7000-0xcf3d2fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcf3d3000-0xcf3f7fff] reserved [0.00] BIOS-e820: [mem 0xcf3f8000-0xcf43afff] ACPI NVS [0.00] BIOS-e820: [mem 0xcf43b000-0xcf5bafff] usable [0.00] BIOS-e820: [mem 0xcf5bb000-0xcf6e6fff] reserved [0.00] BIOS-e820: [mem 0xcf6e7000-0xcf6e] usable [0.00] BIOS-e820: [mem 0xcf6f-0xcfff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffe0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00012fff] usable [0.00] NX (Execute Disable) protection: active [0.00] e820: update [mem 0x021da018-0x021ea057] usable ==> usable [0.00] e820: update [mem 0x021da018-0x021ea057] usable ==> usable [0.00] e820: update [mem 0x020d9018-0x020e5857] usable ==> usable [0.00] e820: update [mem 0x020d9018-0x020e5857] usable ==> usable [0.00] e820: update [mem 0x02237018-0x02243857] usable ==> usable [0.00] e820: update [mem 0x02237018-0x02243857] usable ==> usable [0.00] e820: update [mem 0x02215018-0x0221d057] usable ==> usable [0.00] e820: update [mem 0x02215018-0x0221d057] usable ==> usable [0.00] extended physical RAM map: [0.00] reserve setup_data: [mem 0x-0x0009] usable [0.00] reserve setup_data: [mem 0x000a-0x000f] reserved [0.00] reserve setup_data: [mem 0x0010-0x020d9017] usable [0.00] reserve setup_data: [mem 0x020d9018-0x020e5857] usable [0.00] reserve setup_data: [mem 0x020e5858-0x021da017] usable [0.00] reserve setup_data: [mem 0x021da018-0x021ea057] usable [0.00] reserve setup_data: [mem 0x021ea058-0x02215017] usable [0.00] reserve setup_data: [mem 0x02215018-0x0221d057] usable [0.00] reserve setup_data: [mem 0x0221d058-0x02237017] usable [0.00] reserve setup_data: [mem 0x02237018-0x02243857] usable [0.00] reserve setup_data: [mem
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Sun, Apr 10, 2022 at 9:40 PM James Hilliard wrote: > > On Sun, Apr 10, 2022 at 1:36 PM Patrik Jakobsson > wrote: > > > > On Sat, Apr 9, 2022 at 6:23 AM James Hilliard > > wrote: > > > > > > Select the efi framebuffer if efi is enabled. > > > > > > This appears to be needed for video output to function correctly. > > > > > > Signed-off-by: James Hilliard > > > > Hi James, > > EFI_FB is its own driver and not needed by gma500 to drive its > > hardware. What makes you think it's required? > > I wasn't getting any HDMI video output without it enabled for some reason, > I assume it is doing some sort of initialization needed by gma500 > during startup. Then it sounds like you might just be using EFI_FB and not gma500. Can you provide the kernel log with drm.debug=0x1f set on kernel command-line. What machine is this? I've seen very few gma500 devices with UEFI. > > > > > -Patrik > > > > > --- > > > Changes v2 -> v3: > > > - select EFI_FB instead of depending on it > > > Changes v1 -> v2: > > > - use depends instead of select > > > --- > > > drivers/gpu/drm/gma500/Kconfig | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/gma500/Kconfig > > > b/drivers/gpu/drm/gma500/Kconfig > > > index 0cff20265f97..a422fa84d53b 100644 > > > --- a/drivers/gpu/drm/gma500/Kconfig > > > +++ b/drivers/gpu/drm/gma500/Kconfig > > > @@ -2,11 +2,13 @@ > > > config DRM_GMA500 > > > tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" > > > depends on DRM && PCI && X86 && MMU > > > + depends on FB > > > select DRM_KMS_HELPER > > > # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like > > > i915 > > > select ACPI_VIDEO if ACPI > > > select BACKLIGHT_CLASS_DEVICE if ACPI > > > select INPUT if ACPI > > > + select FB_EFI if EFI > > > help > > > Say yes for an experimental 2D KMS framebuffer driver for the > > > Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and > > > -- > > > 2.25.1 > > >
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Sun, Apr 10, 2022 at 1:36 PM Patrik Jakobsson wrote: > > On Sat, Apr 9, 2022 at 6:23 AM James Hilliard > wrote: > > > > Select the efi framebuffer if efi is enabled. > > > > This appears to be needed for video output to function correctly. > > > > Signed-off-by: James Hilliard > > Hi James, > EFI_FB is its own driver and not needed by gma500 to drive its > hardware. What makes you think it's required? I wasn't getting any HDMI video output without it enabled for some reason, I assume it is doing some sort of initialization needed by gma500 during startup. > > -Patrik > > > --- > > Changes v2 -> v3: > > - select EFI_FB instead of depending on it > > Changes v1 -> v2: > > - use depends instead of select > > --- > > drivers/gpu/drm/gma500/Kconfig | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig > > index 0cff20265f97..a422fa84d53b 100644 > > --- a/drivers/gpu/drm/gma500/Kconfig > > +++ b/drivers/gpu/drm/gma500/Kconfig > > @@ -2,11 +2,13 @@ > > config DRM_GMA500 > > tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" > > depends on DRM && PCI && X86 && MMU > > + depends on FB > > select DRM_KMS_HELPER > > # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915 > > select ACPI_VIDEO if ACPI > > select BACKLIGHT_CLASS_DEVICE if ACPI > > select INPUT if ACPI > > + select FB_EFI if EFI > > help > > Say yes for an experimental 2D KMS framebuffer driver for the > > Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and > > -- > > 2.25.1 > >
Re: [PATCH v3] drm/gma500: depend on framebuffer
On Sat, Apr 9, 2022 at 6:23 AM James Hilliard wrote: > > Select the efi framebuffer if efi is enabled. > > This appears to be needed for video output to function correctly. > > Signed-off-by: James Hilliard Hi James, EFI_FB is its own driver and not needed by gma500 to drive its hardware. What makes you think it's required? -Patrik > --- > Changes v2 -> v3: > - select EFI_FB instead of depending on it > Changes v1 -> v2: > - use depends instead of select > --- > drivers/gpu/drm/gma500/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig > index 0cff20265f97..a422fa84d53b 100644 > --- a/drivers/gpu/drm/gma500/Kconfig > +++ b/drivers/gpu/drm/gma500/Kconfig > @@ -2,11 +2,13 @@ > config DRM_GMA500 > tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" > depends on DRM && PCI && X86 && MMU > + depends on FB > select DRM_KMS_HELPER > # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915 > select ACPI_VIDEO if ACPI > select BACKLIGHT_CLASS_DEVICE if ACPI > select INPUT if ACPI > + select FB_EFI if EFI > help > Say yes for an experimental 2D KMS framebuffer driver for the > Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and > -- > 2.25.1 >
Re: [PATCH v3] drm/gma500: depend on framebuffer
Hi-- On 4/8/22 21:23, James Hilliard wrote: > Select the efi framebuffer if efi is enabled. > > This appears to be needed for video output to function correctly. > > Signed-off-by: James Hilliard Acked-by: Randy Dunlap > --- > Changes v2 -> v3: > - select EFI_FB instead of depending on it > Changes v1 -> v2: > - use depends instead of select > --- > drivers/gpu/drm/gma500/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig > index 0cff20265f97..a422fa84d53b 100644 > --- a/drivers/gpu/drm/gma500/Kconfig > +++ b/drivers/gpu/drm/gma500/Kconfig > @@ -2,11 +2,13 @@ > config DRM_GMA500 > tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" > depends on DRM && PCI && X86 && MMU > + depends on FB > select DRM_KMS_HELPER > # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915 > select ACPI_VIDEO if ACPI > select BACKLIGHT_CLASS_DEVICE if ACPI > select INPUT if ACPI That "select INPUT" is really bad -- but not your problem. In the entire kernel tree there are only 3 drivers that select INPUT, and they are all in drivers/gpu/drm/. > + select FB_EFI if EFI > help > Say yes for an experimental 2D KMS framebuffer driver for the > Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and thanks. -- ~Randy
[PATCH v3] drm/gma500: depend on framebuffer
Select the efi framebuffer if efi is enabled. This appears to be needed for video output to function correctly. Signed-off-by: James Hilliard --- Changes v2 -> v3: - select EFI_FB instead of depending on it Changes v1 -> v2: - use depends instead of select --- drivers/gpu/drm/gma500/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig index 0cff20265f97..a422fa84d53b 100644 --- a/drivers/gpu/drm/gma500/Kconfig +++ b/drivers/gpu/drm/gma500/Kconfig @@ -2,11 +2,13 @@ config DRM_GMA500 tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" depends on DRM && PCI && X86 && MMU + depends on FB select DRM_KMS_HELPER # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915 select ACPI_VIDEO if ACPI select BACKLIGHT_CLASS_DEVICE if ACPI select INPUT if ACPI + select FB_EFI if EFI help Say yes for an experimental 2D KMS framebuffer driver for the Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and -- 2.25.1
