[haiku-appserver] Re: input issues

  • From: Michael Lotz <mmlr@xxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Fri, 15 Apr 2005 21:00:26 +0200

Stephan Assmus wrote:
 > The DisplayDriver class has methods for querying the possible
 > resolutions and all, which should already work AFAIKT.

It is implemented for the (old) AccelerantDriver and the 
AccelerantHWInterface (ProposeMode(), GetTimingConstraints(), 
GetPixelClockLimits() and GetModeList()). I didn't really test these, 
but the accelerant design is so straight forward, that I can't imagine 
them not to work.

Axel Dörfler wrote:
 > 3) while the RootLayer seems to be where input/output come together,
 > for some strange reason, the display driver (!) must create the
 > input_server listener port...

This is a leftover from when the app_server could only be tested with 
the ViewDriver. From ViewDriver.cpp just above the port creation:

        // This link for sending mouse messages to the OBAppServer.
        // This is only to take the place of the Input Server.

It was created to be able to emulate the input_server using the VDView 
hook functions. I only implemented this code in the Accelerant drivers 
because it was done nowhere else. As we now have a fake_input_server 
doing this and the real input_server, we should move this out of there. 
If you want to go for the "different users can have different workspaces 
and their own input/output hardware" we should place it into RootLayer 
as, as I understood it, each workspace has it's RootLayer that manages 
input/output stuff like mouse handling and cursor management.

Axel Dörfler wrote:
 > 1) as I said, the input_server is not yet started by our app_server.
 > This, for example, was the reason why I never got any input; I just
 > didn't know that this part is missing from the app_server

I could implement this using the code of consoled if noone else has 
already looked into it. On my system, I just start the input_server from 
the Bootscript after the app_server and registrar to work around this.

To get to some other "input issues": I simply can't get my mouse to 
work. I investigated this for quite some time now and I just don't get 
the problem. Somehow my PS/2 controller just does not allow for 
communication between the mouse driver and the real mouse device. I 
found out so far that whatever I do, I always get PS2_RES_RESEND as a 
result to any request to the aux_device (mouse). I tried with resetting 
the mouse (looked at the freebsd implementation for this - horrible to 
understand, it takes you an hour alone to find out that you're looking 
in the wrong place) but all I get is PS2_RES_RESEND.
When I plug it into the actual PS/2 port (using the USB adapter) the 
mouse itself starts to flash (as it does normally when it's sending some 
kind of data), but still I only get PS2_RES_RESEND from the controller. 
I even get these results when I unplug the mouse completely, so I think 
it has to do with the setup of the controller itself and not the device. 
I by the way tried with and without USB legacy support in the BIOS and 
the mouse works as a ps2 device under R5 with the USB adapter.

Another thing that I noticed when playing around with that code was, 
that appearantly the keyboard driver thinks it should handle what we 
want to send to the controller. When setting the command byte for 
example, the handle_keyboard_interrupt() function is triggered and the 
keyboard driver tries to dispatch the result as a keydown. I found out 
that freebsd locks the keyboard during mouse setup. I think that we 
should even disable_interrupts() while doing mouse setup because the 
keyboard device and the auxiliary device (mouse) share some of the 
buffers (as far as I can tell) and they should not get in each others 
way by dispatching just everything that comes in.

If someone has technical specs for PS/2 keyboard/mouse controllers 
please let me know. I found a technical paper on a controller inside the 
mouse, which essentially tells me that we do exactly the right thing in 
our driver. I just don't get the replies the paper describes ;).

(the above thing takes place in 
src/add-ons/kernel/drivers/input/ps2_hid/mouse.c by the way)


Other related posts: