From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <9f78f30e1a29903f8c6f43d685b83110@plan9.escet.urjc.es> To: 9fans@cse.psu.edu Subject: Re: [9fans] cooked mouse mode. From: "Fco. J. Ballesteros" Date: Fri, 14 Jan 2005 15:02:12 +0100 In-Reply-To: <386b6f1952e8adafd3b8682624b05e50@vitanuova.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 2f618248-eace-11e9-9e20-41e7f4b1d025 Well, actually the plan was to get applications use the cooked mode; and get rid of the need for raw mode. Agree that some will have to use it, say, like you do in the console with the keyboard, but that's not the common case. That can probably explain why we wanted a mode change and not a new channel with different semantics for mouse events. But maybe I'm missing your point, am I? >> You have to say >> setmousemode(cooked), >> and then no other thread has a way to get to >> the raw mouse events. > > except that a thread can read from the cooked mouse channel > and *think* that it's reading raw events, with no way > to tell. > > if you're worried about it, you can just nil out the raw mouse > channel in the Mousectl structure.