P96ScreenCX problem with AmiStart utility

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • Hello.


    A bug report for the P96ScreenCx utility:


    When using the popular AmiStart utility for taskbar ( https://aminet.net/package/util/wb/AmiStart ) with the P96ScreenCx for multi monitor support the mouse repositioning does not work anymore properly. When you have Native Monitor on the left side and P96 monitor on the right (RIGHT_OF=Native tooltype) then when you leave one monitor it positions the mouse on the wrong side on the other monitor.

    I have tried all possible tooltypes and settings in AmiStart and couldnt find what would be causing this. As soon as I quit AmiStart the normal behavour is back.

  • Hello.

    The overall configuration is OS 3.2.1, but I have tried with OS 3.2 and OS 3.1 too, the same result. Latest P96 3.22 drivers and everything. I have tried with the older versions of P96 and ScreenCx utility and the same result. Have been using WBDock before but switched to AmiStart because it doesn't consume any CPU when idle and has transparent background possibility.

    Thank you.


    At first I thought it might block the Mouse positioning all-together, but it actually makes the P96ScreenCX utility position the mouse the other way around - on the opposite corner. If it would not do any mouse positioning then the mouse would not be positioned on the far side of the bigger screen, but would stay on 640 X position. So for some reason the ScreenCx utility gets confused with the LEFT/RIGHT positioning on the screen.

  • I have tried with the older versions of P96 and ScreenCx utility and the same result.

    That alone is enough to not look for the fault in P96.


    The mouse movements that are injected are going through input.device. Some other commodity appears to swallow them. The events are synthesized "by the book" - there's nothing you can do wrong about it. Please contact the author of AmiStart.

  • Hi

    My good friend Amigo/Binary helped with investigation of the issue. Thanks to him there is an elegant fix available.

    In a nut shell there is no fault in either P96ScreenCX (as you thought) or AmiStart. The problem is that commodities.library itself removes the events it dispatches forward to the commodities and because it has a priority higher that intuition (int. has 50, commodities has 53) the intuition does not get the evens anymore.

    He fixed it by having an utility that listenes for the same evens with priotiy 51 and puts them back as soon as they arrive so the intuition finally gets the events.

    Works like a charm too.

    If anyone wants the fix and the source, here it is : http://pc.sux.org/tomcat/AmiStartP96ScreenCXFix.zip

  • The archive contains source and binary, but no mention of the author or license that it's under. I understand that it's on the edge of "depth of creation" where copyright might not come into play, but I'm not a fan of legal stunts like this. Credit should be given where credit is due, and we should also know how to handle this piece of software: Freeware? Shareware? Mailware? (L)GPL? Creative commons? Who is allowed to host it, and under which conditions?

  • I'm in regular contact with Thor, and he wrote yesterday that there may be something off in P96 after all. In his own words: "My approach was way too complicated". So the next update might include the simplification that he implied yesterday.

  • The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.