On Wed, Sep 06, 2017 at 05:34:45PM +0300, Ville Syrjälä wrote: > On Wed, Sep 06, 2017 at 03:08:40PM +0100, Chris Wilson wrote: > > Quoting ville.syrjala@xxxxxxxxxxxxxxx (2017-09-06 14:04:01) > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > "echo 1 > vtconN/bind" doesn't actually do anything. Looks like the only > > > way to rebind fbcon is to unbind the current console. > > > > > > I suppose the failure to rebind might be a kernel bug, but I can't be > > > bothered to decode the vt.c spaghetti so let's just try to handle this > > > in igt. For simplicity let's assume the currently bound console is the > > > dummy console and unbind that when we want to rebind fbcon. That works > > > for me. > > > > > > With rebinding not working we can't really tell wich console is going > > > to get bound anyway, so there's no way to make this code really robust, > > > assuming we ever had more than these two console drivers involved. > > > > Hmm, CONFIG_DUMMY_CONSOLE suggests that the dummy isn't universal > > either. If there is no dummy, can the last be unbound? I have no idea. > > DUMMY_CONSOLE isn't user visible and default=y, so you can't actually > disable it, I think. > > It does have some suspicious looking dependencies though: > depends on VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y > > So it gets disabled only if you have both VGA and SGI_NEWPORT enabled. > I suspect someone meant to say '&&' instead of '||'. But for us the '||' > works better since we don't allow rebinding vgacon after it's been > kicked out, and so having dummy+vga is good. We select the dummy con in i915, to be able to kick out vgacon before we register fbdev. So should always be there. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
