OSDev.org

Hi,

Code inside my handler - used to determine the current x and y value of the mouse pointer - Device initialized using default settings
Testing in VPC, the y value overflows constantly. Testing on real hardware, it doesn't appear to overflow, but when I move the mouse up and down, the cursor does not move up or down, when I move the cursor left to right, then the cursor moves up or down. The pattern is that the cursor continues to progress upward until it reaches the top outer edge and then it restarts back at the bottom and continues to act in the same aforementioned way.
I'm using the above code to keep it in bounds.
And, the code above is firing without actually clicking the left button. Triggered by movement.

I have compared my code to a number of different codes, and I am not really seeing much difference, except that I am trying to account for overflow. When I test my code in VGA mode, it works perfectly in VPC and real hardware. But, I am writing this mouse driver to work in a graphical mode (800x600x16M), so I am not too sure if the problem is with my math. I did print out the x and y values right before where I actually print the cursor and both values would be within my screens range, both positive numbers. I do make sure to multiply by screen width and bytes per pixel in the back end, so if it is my math I don't see how it could be.

I hope someone can figure this out or has had this happen to them and can provide a possible solution. Thanks.

Um, your bit test for detecting overflow is wacko.
These should say "& 0x40" and "& 0x80". Right now, the first test should only pass when you are clicking a button, and the second should never pass (except with a cheap mouse).
are also wrong, and should say "& 0x10" and "& 0x20". You may also be having packet alignment problems, but it's hard to tell.

Also, I don't think the way you deal with negative deltaX and deltaY values will work. It is not a matter of just subtracting something that looks like a positive displacement. You have to create a negative number, and add it in, instead.

That is, a downward movement of one pixel should give you a deltaY value of 0xff, not 1 (with the "negative" bit (0x20) set in the bitflags byte). If you try to subtract 0xff, your cursor will move all wrong.

Hi,

I have been racking my brain over this for some time now. I have tried coding my handler at least 50 different ways. I have tried source after source, and something strange I found.

When my OS starts, the GUI is drawn. My cursor only moves up or down. I can maneuver it to a control. All while the mouse is generating clicks as movement is made, the x-values change only slightly, the y-values change rapidly. Once I manage to click an item in my menu, it calls a function, the function completes, and all of a sudden my mouse is working just fine!

I have tried simulating clicks of this same function at start with no avail. It only begins to work once I have clicked a menu item related this function I told you about. The function simply reads a hard disk, that's it. I have several menu items that use this same function, it is the only function that I have been able to test as it is the only function that is available to me until the mouse is working. I observed my code in detail and nothing jumps out at me as wrong or at least even responsible for creating this sudden change in the mouse's behavior.

What could the problem possibly be, how could I test for it, and what would you suggest I do next? Thanks

I would suggest looking through your menu clicking functions and related stuff to see if it alters any mouse conditions.

I've done that already. I see nothing. It seems as if the mouse is out of sync until this function is ran via a literal click of the mouse. As if the packets are misaligned. I cannot simulate this click and get the same results. It must be a physical click. That pretty much rules out the function ideal, IMO. Still unsure of what to try. Thanks

By "simulation of the click" you mean sending the appropriate packets, right? Ten invisible tokens says that there's a magic number or two out of place in either the simulation or the receiving function.

[offtopic]Whee, seven spelling mistakes caught before posting, huzzah for late-night posting![/offtopic]

Of course not. The mouse generates clicks on its own. It isn't about whether or not the mouse is generating clicks. I mean that I am simulating clicking the menu items that when actually clicked will fix the mouse. I assumed that if I would simulate a click of the menu item, thus setting my function in motion, that the mouse would work on its own. It does not. It must be a literal click of the literal menu item. I cannot just call my function and expect it to work, because it does not. I will keep investigating various parts of my kernel to try and track down the responsible code, so if anyone has any idea, sounds like something you faced and fixed, then please jump in at anytime. I am willing to wager that it has something to do with memory. Misalignment in packets. Something along those lines. Not sure really without much to go on. I have a few clues but they seem to contradict each other. Unknown. Thanks

What if you click, but not on the menu? Does it work then? Also, do you read the entire PS/2 buffer or only a few bytes?

Only a few bytes. I just ask for the delta values, and attempt to determine when the left button is clicked, nothing more. I attempt to handle overflow based on these delta values.

No, clicking does nothing, before fixing itself a click registers as upward movement. I have to actually get the cursor close to the menu and shake it, then a click is generated. After this, the mouse is fully functional. I started messing around with the global array I am using to save the packets. When I make it unsigned, it does nothing, when I make it signed, it acts as before. Could it be possible that my char array could start misaligned and somehow fix itself? I don't know. If I declare a variable outside a function, is that heap or stack memory? Thanks

If I declare a variable outside a function, is that heap or stack memory?

Neither. It's either in a data section or a BSS section.

The problem sounds to me like reading the data out-of-order. Are you certain that your code ensures that it saves the packets correctly - the first packet to index 0, second to index 1, etc?

Shooting at the dark here since I've never done anything like this before, but have you tried reading the entire PS/2 buffer? It sounds like there's something in the buffer you're not expecting, and reading the entire buffer and just ignoring that unexpected part might help you resync the packets. Of course, once again, I'm just shooting at the dark and saying the most logical thing that comes to mind...

The problem, I think, was this. Bewing said it first, but pcmattman said it best. My char array seems to be saving the packets at the wrong indexes. After I read pcmattman's post i went directly to my code and fudged up the numbers a bit to try and recreate the same affects I was getting on real hardware in VPC. And, very much to my surprise, the mouse started acting just like it did on real hardware. It was too late to say anything, so I went to bed. I haven't had the chance yet to work with it more, but I am almost positive now that I found the problem. I'll let you know if I solve this. Thanks

Cool, I finally got it working! It isn't perfect yet, but at least it is acting like it should from the start. I still need to make a click, but now that can happen anywhere now, so at least I know now that I am headed in the right direction.

For you guys who might need some help. Here are some things to consider:

01. Make sure you store the packets at the correct index. (i.e., packet 0, goes to index 0, etc.).
02. I haven't found a huge need to handle over-flow but you might just to be precise.
03. Align your cursor at the center, I found that it is helpful for locating it at the start. x=(screen_width/2)-(cursor_width/2), y=(screen_height/2)-(cursor_height/2)
04. Read this: http://www.computer-engineering.org/ps2mouse/

The rest is pretty easy to figure out. Thanks