22 January 2022, 22:18 | #341 |
Retro Freak
Join Date: Nov 2001
Location: Slovenia
Age: 51
Posts: 1,649
|
Unfortunetly it is not developed anymore. The native screen has much lower horizontal resolution but it will position the mouse to the furthest right on the new screen, it will not leave the mouse on the same position as on the previous screen... So for some reason it thinks the monitors are in the wrong order.
|
23 January 2022, 10:25 | #342 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,251
|
There are two aspects here I should clarify:
First, please understand that this utility is not part of P96 and not distributed as part of P96. It is solely authored by me and distributed by me. See also the ReadMe that came with it. Thus, please do not post at iComp, they are not related to this thing. Second, a technical aspect, maybe I wasn't clear: If the mouse leaves the current screen, P96ScreenCx does two things: It first triggers a screen switch (ScreenToFront()), but this leaves the mouse position in its original place. Second, it moves the mouse to the opposide edge of the new screen to create the illusion that the two screens are side-by-side. This mouse movement is performed by synthesizing mouse movement events through a well-known mechanism of the input.device of a system. For a reason unclear to me, AmiStart seems to swallow these synthetic mouse movement events. Long story short: I wouldn't know how to solve this problem. I cannot synthesize mouse movement events to push the pointer to the right place in any other way; the current way is the system way. However, I do not know the backgrounds of AmiStart well enough. Thus, either do without Amistart, or do without P96ScreenCx, there is nothing what I can do, I am sorry. |
23 January 2022, 10:42 | #343 |
Retro Freak
Join Date: Nov 2001
Location: Slovenia
Age: 51
Posts: 1,649
|
Thank you for the explanation. Really appretitated... Will try debugging it with a friend, maybe he comes up with something
|
24 January 2022, 12:56 | #344 |
Retro Freak
Join Date: Nov 2001
Location: Slovenia
Age: 51
Posts: 1,649
|
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 have 53) the intuition does not get the events anymore. He fixed it by having an utility that listens for the same events with priority 51 and puts them back as soon as they arrive so the intuition finally gets them. Works like a charm too. If anyone wants the fix and the source, here it is : http://pc.sux.org/tomcat/AmiStartP96ScreenCXFix.zip |
24 January 2022, 14:06 | #345 |
WinUAE 4000/40, V4SA
Join Date: Apr 2020
Location: East of Oshawa
Posts: 538
|
You or your friend should get that uploaded on Aminet if it hasn't already been. Although seeing as it isn't a fix for P96ScreenCX exactly but rather a workaround for commodities, perhaps with a different name.
|
24 January 2022, 17:03 | #346 | |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,043
|
Quote:
Namely, events get nullified because class=RAWMOUSE shouldn't have a subclass *afaik*, but his utility is setting it to $10 (couldn't find anything in 3.0 includes, so not sure whether it's some private intuition/input flag, or his own flag e.g. to be able to identify fake event later on when they get dispatched, or something else), which then results in commodities.library event handler at 53 to nullify them: if subclass is not 0 (plus some extra conditions for class=NEWPOINTERPOS that are irrelevant), that for RAWMOUSE events means nullification, and intuition at 50 doesn't get to have them. |
|
24 January 2022, 17:40 | #347 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,251
|
The commodities library does not filter input events out that go "downstream" to intuition, but only those that go to into its handlers, otherwise the commodity would not work at all. The value 0x10 is used here to achieve exactly that, it indicates that the event is "synthetic". The problem P96ScreenCx has to solve is that the synthetic mouse event created by the commodity should not trigger another "recursive" screen switch by the mouse reaching the other end of the screen as part of reaction on the event. The tool cannot know how many mouse ticks the mouse has to travel to reach the other end of the screen and thus may, without a further indication, trigger a switch.
|
24 January 2022, 18:08 | #348 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,043
|
Yeah, I understand that. They get removed when the app is running (it's using cx for event handling, I typically use either IDCMP or input.device so can't tell more about this first hand, and how to avoid it.. exe is ~1MB), but this could be generalized for an arbitrary app?
I did a test earlier with a prio=100 handler that sets subclass of those events to 0 and it doesn't work: events are perpetually generated (as you pointed out) and mouse becomes unusable. However, wouldn't it be sufficient to use class+subclass+code+x+y combo (rawmouse, 0, nobutton, +/-4095, 0, all legit values) to correctly identify them with 99.9% repeating, and avoid a "problematic" private subclass that cx handler apparently doesn't like (it only allows documented subclasses: $00-$03 for class=NEWPOINTERPOS)? Either way, I don't have a horse in this race, just an opinion about choosing between 2 evils. |
24 January 2022, 19:23 | #349 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,251
|
Actually, what I did there was all just too complicated. Please find a test version attached and please report back.
|
24 January 2022, 19:27 | #350 | |
Retro Freak
Join Date: Nov 2001
Location: Slovenia
Age: 51
Posts: 1,649
|
Quote:
Thank you ! Last edited by tomcat666; 24 January 2022 at 19:33. |
|
24 January 2022, 19:30 | #351 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,043
|
|
25 January 2022, 06:45 | #352 |
Registered User
Join Date: Dec 2017
Location: Germany
Posts: 9
|
|
25 January 2022, 16:26 | #353 |
Ancient Amiga User
Join Date: Mar 2018
Location: Elkhart, IN USA
Posts: 208
|
|
31 January 2022, 00:02 | #354 |
Registered User
Join Date: Oct 2012
Location: Germany
Posts: 585
|
@Thomas updated P96screencx to latest Aminet version. Works fine, except for one oddity:
- screen 1: native - screen 2: rtg pubscreen in front of rtg workbench Moving pointer between 1 and 2 is fine (TT ActivateWindow is enabled). Now we hit close gadget of the program (YAM) on the MUI pubscreen (screen 2) and move to screen 1 before the pubscreen is closed. Now Screen 2 closes, but the screen stays grey (screen background color). Only switching the screen manually or moving the pointer back to screen 2 will make the grey background vanish and Workbench reappear. |
01 February 2022, 18:38 | #355 |
Registered User
Join Date: Nov 2021
Location: USA
Posts: 26
|
Thanks Thomas for documenting ENV and Tooltypes here on EAB -- would be nice to have these new descriptions in the P96 guide file in the P96 package. Also, I have noticed the HISTORY readme file that is in the lha does not get copied during the install process. Having the history file copied and a link in the guide would be nice too.
|
02 February 2022, 14:26 | #356 |
Bug hunter
Join Date: Jul 2006
Location: Italy
Age: 48
Posts: 2,165
|
|
02 February 2022, 17:47 | #357 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,251
|
I would prefer to move the guide to a wiki on the icomp page, this is easier to maintain and to update for me.
|
02 February 2022, 17:49 | #358 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,251
|
Actually, as of today, a new version of P96 was provided. It's now release 3.2.3, with the following changes:
- P96 no longer attempts to set the beamcon0 register and the vtotal register of the custom chips in case the active video mode is on an RTG board that is not in the display chain. - Even though bitmaps were locked, memory management could have migrated them off the board if memory was getting tight. This may have caused quite some issues on "close-to-zero" memory situations. - As BlitMaskBitMap was potentially allocating memory for the mask buffer, it could have migrated the bitmaps it was actually supposed to render, causing all kinds of havocs. To avoid this problem, source and target bitmap for a two-bitmap operation are now locked on the board. This is actually a very old bug that goes back to the 2.x release cycle. - A possible memory inconsistency in P96Mode was fixed where an incorrect memory pointer was released. - The Altais and RetinaBLT drivers did not record the state of the monitor switch correctly. As a result of this defect, the SetDPMS() function to enable power saving may have failed, keeping the monitor on all the time. - The rtg.library may have attempted to switch of the Altais display on a Draco system without ever turning it on again. - Fixed a very old bug on adjusting the line pattern shift upon drawing into multiple cliprects. This bug was apparently introduced while merging my own P96 version with the last official version by the authors. This bug could have introduced artefacts when drawing "marquee" effects for selecting multiple files in alternative file managers. - When switching buffers on a double-buffered screens, P96 forcibly reloaded the sprite image, which caused flicker on some RTG boards. This version now avoids reloading the sprite unless absolutely necessary. As always, I will provide some more details in the next days. |
02 February 2022, 18:27 | #359 |
Bug hunter
Join Date: Jul 2006
Location: Italy
Age: 48
Posts: 2,165
|
WOW! Lots of releases in recent times!
|
02 February 2022, 20:38 | #360 |
Amigan
Join Date: Feb 2012
Location: London
Posts: 1,311
|
Thanks Thomas!
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
P96: What's the right way to do X? | Warty | Coders. General | 2 | 21 December 2020 00:00 |
Providing 2 fire button support / cd32 joypad support | amigapd | request.Other | 0 | 13 July 2015 17:20 |
Portaudio support (was: WinUAE support for ASIO drivers) | Amiga1992 | support.WinUAE | 57 | 28 March 2009 21:15 |
Classic WB P96 | Anubis | project.ClassicWB | 5 | 08 May 2006 14:30 |
amiga-news.de: Collected software-news | Paul | News | 0 | 14 November 2004 15:50 |
|
|