Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 21 Oct 2001 13:18:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 21 Oct 2001 13:18:09 -0400 Received: from www.transvirtual.com ([206.14.214.140]:54532 "EHLO www.transvirtual.com") by vger.kernel.org with ESMTP id ; Sun, 21 Oct 2001 13:18:01 -0400 Date: Sun, 21 Oct 2001 10:18:15 -0700 (PDT) From: James Simmons To: Alan Cox cc: Allan Sandfeld , linux-kernel@vger.kernel.org Subject: Re: The new X-Kernel ! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > > We have the AGP, DRM and framebuffer drivers in the kernel anyway. It would > > make sense to do all the autodetection in kernelspace, and let the info be > > available to the X-server. I would love to kill all the hardware specific > > stuff in /etc/XF86Config, especially the keyboard and mouse stuff that > > belongs in or near the kernel. > > Quite the reverse. The handling for mice/keyboards and dynamic changes of > keyboard/mouse need to be in X11. I disagree. Mice and keyboards are becoming more complex. To the point where the hardware state has to be managed between processes in a possible SMP system. Consider mice with force feedback. If several process program the mouse to vibrate at the smae time it sums all the values up. You can end up breaking the mouse because it vibrated to hard. Also look at the problems GPM and X have had before. This problem gets more complex as more pieces of software that play around with mice and keyboards emerges besides X or even while running in X. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/