[PATCH 4/6] libweston: fbdev: set fb device info upon the first run.

[Pekka Paalanen]

On Mon, 02 Oct 2017 23:14:26 -0400
nerdopolis <bluescreen_avenger at verizon.net> wrote:

> On Tuesday, September 26, 2017 9:45:43 AM EDT Pekka Paalanen wrote:
> > On Thu, 14 Sep 2017 23:08:51 -0400
> > nerdopolis <bluescreen_avenger at verizon.net> wrote:
> >   
> > > On Wednesday, September 6, 2017 8:17:21 AM EDT nerdopolis wrote:  
> > > > This attempts to wake up secondary framebuffer devices
> > > > (/dev/fb1 and up) as usually these devices start powered off, and
> > > > the FBIOPUT_VSCREENINFO ioctl turns it on. This was tested on a
> > > > qemu system with the options:
> > > > 
> > > > -vga none -device VGA,id=video0 -device secondary-vga,id=video1 \
> > > > -device secondary-vga,id=video2
> > > > ---
> > > >  libweston/compositor-fbdev.c | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/libweston/compositor-fbdev.c b/libweston/compositor-fbdev.c
> > > > index b4f0685c..a9cc08be 100644
> > > > --- a/libweston/compositor-fbdev.c
> > > > +++ b/libweston/compositor-fbdev.c
> > > > @@ -356,6 +356,13 @@ fbdev_frame_buffer_open(struct fbdev_output *output, const char *fb_dev,
> > > >  		return -1;
> > > >  	}
> > > >  
> > > > +	/* Attempt to correct the framebuffer settings */
> > > > +	if (fbdev_set_screen_info(output, fd,
> > > > +	                          &output->fb_info) < 0) {
> > > > +		weston_log("Failed to set mode settings. "
> > > > +		           "Attempting to open output anyway.\n");
> > > > +	}
> > > > +
> > > >  	/* Grab the screen info. */
> > > >  	if (fbdev_query_screen_info(output, fd, screen_info) < 0) {
> > > >  		weston_log("Failed to get frame buffer info: %s\n",
> > > >     
> > > Hi
> > > 
> > > Nix this one, I tried it on a UDL (USB display link device) framebuffer, and it
> > > changes the resolution/vsync that my screen cannot handle, and I'll need to 
> > > figure out why it does that (as UDL (the framebuffer only one) starts off) with
> > > the screen all green...
> > > 
> > > ...It worked for QEMU, but not for real hardware
> > > 
> > > Sorry about this...
> > > ...I'll try to see what I can come up with, and why it does that....  
> > 
> > Hi,
> > 
> > yeah, we definitely do not want to set_screen_info before first
> > query_screen_info. If there is something valid set already, we want to
> > keep it. If there is not, then how do you know what to set?
> > 
> > What screen info values do you think this patch is setting? All
> > zeroes? ;-)
> >   
> Thanks for all the reviews!
> 
> This was an attempt to use the fact that set_screen_info sends the 
> FBIOPUT_VSCREENINFO ioctl, which turns on the screen (if it's a /dev/fb1 as 
> those usually are off upon boot. At least with the DisplayLink devices, and 
> secondary-vga devices I've tested on)
> 
> I seem to have fixed this, It works on my QEMU configuration I mentioned,
> it does not throw my screen out of wack on real hardware, but I think there is 
> a bug with UDL (displaylink) or something where Plymouth starts, and freezes 
> the display, and prevents the framebuffer from displaying (even when I cat 
> /dev/urandom
> into /dev/fb1 as a test...
> 
> This is with the udl driver (not udlfb), ...and this might be out of the
> concern of Weston.

Hm, wouldn't Plymouth be using DRM KMS, not fbdev?
KMS usage will "hide" the fbdev contents by design. A bug in the driver
is possible, or then the KMS usage in both Weston and Plymouth is
missing bits, like handling pageflips never working or not setting
dirty rects or something. Oh yeah, Weston doesn't do multi-card either.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171003/40b8d5fe/attachment.sig>