Add a new VT mode which is like VT_PROCESS but doesn't require a VT_RELDISP ioctl call
in [Kernel]
|
From: Alan Cox on 19 Feb 2010 05:50 > If the X server eventually uses this new mode, debugging and crash > recovery should become easier. This is because even when currently in > the VT of a frozen X server it would still be possible to switch out > by doing SysRq-r and then CTRL-<number of a text vt>, sshing in and > doing chvt <number of a text vt>, or any other method of VT switching. > The general concensus on #xorg-devel seems to be that it should be > safe to use this with X now that we have KMS. > > Signed-off-by: Ari Entlich <atrigent(a)ccs.neu.edu> If KMS doesn't need to mode switch then does it need any of this stuff - can it not just switch to a console and use it ? Otherwise please use a different value than ACKACQ (just for clarity) and conceptually it looks fine to me - I just question if it's really needed as KMS based X not having to play with magic locking stuff would be cleaner still. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 19 Feb 2010 07:10 > 1. VT_AUTO doesn't send signals to anything when a VT switch happens, precisely > because VT_AUTO is supposed to be used in the case where there's nothing to > send signals TO (i.e. the VT is managed by the kernel). The X server still > needs to know about VT switches to turn input devices off and such. Ok.. > VT_ACKACQ, it wouldn't really make sense for there to be a new VT_ACKACQ value, > because VT_ACKACQ is something which gets passed to a VT_RELDISP, and VT_RELDISP > isn't needed at all in this new mode. I don't want to change the existing values as they are somewhat visible to user space. > I hope that clarifies things. Yes. You could use the VT_EVENT facility for the switch monitoring but the asynchronous nature of the reporting probably isn't what is needed for input device switching etc. Looks fine to me - just bump the value and resubmit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ari G. Entlich on 19 Feb 2010 07:10 ----- "Alan Cox" <alan(a)lxorguk.ukuu.org.uk> wrote: > If KMS doesn't need to mode switch then does it need any of this stuff- > can it not just switch to a console and use it ? Otherwise please use a > different value than ACKACQ (just for clarity) and conceptually it looks > fine to me - I just question if it's really needed as KMS based X not > having to play with magic locking stuff would be cleaner still. I'm not positive I understand what you're saying. Are you asking why we can't just use VT_AUTO now? That's something I investigated, and there are a couple reasons why it wouldn't be suitable: 1. VT_AUTO doesn't send signals to anything when a VT switch happens, precisely because VT_AUTO is supposed to be used in the case where there's nothing to send signals TO (i.e. the VT is managed by the kernel). The X server still needs to know about VT switches to turn input devices off and such. 2. The kernel ignores VT switches when switching away from a VT which is in KD_GRAPHICS + VT_AUTO mode. I'm not sure what the reason for this is, and I'm also not sure why it doesn't ignore switches TO these sorts of VTs, but that's the reality and my impression is that it's generally not a good idea to change these sorts of things when they've been in place for this long. Is this what you were asking about? Also, in terms of what you said about VT_ACKACQ, it wouldn't really make sense for there to be a new VT_ACKACQ value, because VT_ACKACQ is something which gets passed to a VT_RELDISP, and VT_RELDISP isn't needed at all in this new mode. I hope that clarifies things. Thanks! Ari -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ari G. Entlich on 19 Feb 2010 08:20 ----- "Alan Cox" <alan(a)lxorguk.ukuu.org.uk> wrote: > I don't want to change the existing values as they are somewhat visible > to user space. Sorry if I was unclear - I wasn't talking about changing the value, I was just saying that VT_ACKACQ and VT_PROCESS_AUTO are used in different contexts, so it shouldn't matter that they have the same value. One thing that probably would be nice though would be to move the VT_ACKACQ define to a different place in vt.h (probably after the VT_RELDISP define). > Yes. You could use the VT_EVENT facility for the switch monitoring but > the asynchronous nature of the reporting probably isn't what is needed > for input device switching etc. Yeah, it looks like the X server would have to be constantly blocking inside a VT_WAITEVENT ioctl in order to use that, and then it wouldn't be getting anything else done. :-/ Ari -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 19 Feb 2010 09:20
> Sorry if I was unclear - I wasn't talking about changing the value, I was > just saying that VT_ACKACQ and VT_PROCESS_AUTO are used in different > contexts, so it shouldn't matter that they have the same value. One thing > that probably would be nice though would be to move the VT_ACKACQ define > to a different place in vt.h (probably after the VT_RELDISP define). That would just as well. It just needs to be obvious for future maintainers that the overlap doesn't matter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |