Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Hollywood MAL AMIStore App Store A600 Memory

AuthorTopic: The Os 3.1.4 Thread  (Read 59581 times)

0 Members and 4 Guests are viewing this topic.

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #585 on: August 14, 2019, 01:59:03 PM »
No...it’s not an OS 4 machine it’s an A1200.  I noticed this error while searching for info on Hyperion’s web site.  I had iPrefs crash repeatedly on 3.1.4 which, just guessing, must share some of the same code as OS4.
No, it is not. The IPrefs from 3.1.4 is essentially one of the versions from 3.9. I am not aware of any defect there. If you see a crash, I would like to have the MuForce output as I have no defect on file for it.

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #586 on: August 14, 2019, 02:01:58 PM »
Well, from users' perspective, that is rather irrelevant distinction.
Not really. It is a defect of the delivered USB stack, and it should have been done correctly in the stack in first place. Delivering an alternative input.device was never the right solution in first place - this was the kludge to begin with.
That's easy to say 15-20 years later. When Chris was developing Poseidon, this may not have been so obvious for him, and also his focus was forward, towards MorphOS. Unlike you, he couldn't use OS 3.1 sources as reference. Anyways - you were around too, so why didn't you do anything... The "kludge" has been the fix for the last 20 years or so, if OS 3.1.4 input.device comes with a better "solution", then fine... guess I could give it a whirl, the software license be damned.

Quote
One way or another, this issue has been addressed, but in how far an updated Poseidon stack can be delivered is something I cannot decide. All I can say is that I took precautions to address the problem, and I did my best to provide a solution.
Poseidon sources are available, I don't see what would disallow you to fix things "properly" if you so wish.

Btw - I notice that there is quite a brawl on the apollo-core forum about you and your opinions, mr ppcamiga1 :)
( http://www.apollo-core.com/knowledge.php?b=1&note=17502&x=6&z=fuqLnm )
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #587 on: August 14, 2019, 02:29:07 PM »
That's easy to say 15-20 years later. When Chris was developing Poseidon, this may not have been so obvious for him, and also his focus was forward, towards MorphOS.
Look, this is all speculation. Whether this was obvious, whether it was not, whether it was intended or not. I do not know. The fix was done at the wrong end - it is too late for a change.

Unlike you, he couldn't use OS 3.1 sources as reference.
For this, you do not need any sources. You only need to know the documentation of IND_WRITEEVENT. Actually, the docs say it all: It sends the given event down the stream of input event handlers. That is it, and the source for the input.device do not tell you anything beyond this. For reasons unknown to me, Chris seemed to  assume or require that it also creates synthetic keyboard repeat events, but it is not promised by the interface at all. And actually *should not*. If it would, it would break software such as FKey or commodities in general as they may create more events than intended, and different events than intended.

Anyways - you were around too, so why didn't you do anything...
You seem to believe that you have the right to demand service from me. How come? So, let's straighten up things for you again: I am not your AmigaOs service personell. First, I did not have Poseidon back then when Chris wrote it. How should I possibly be responsible for something I did not write, I did not use, I did not own and I was not even aware of. If he'd asked, I would have told him, but this is all years ago.  We are doing something for it right now as the problem was reported, and that is the earliest point at which a problem can be handled.

The "kludge" has been the fix for the last 20 years or so, if OS 3.1.4 input.device comes with a better "solution", then fine... guess I could give it a whirl, the software license be damned.
The input device of 3.1.4 is the same as that of 3.1, and the only new thing it added was NSD. It does not provide any better solution than 3.1, but as of 3.1, there was already a correct way of doing it, namely create synthetic keyboard events yourself for keyboard repeat. Why Chris did not do that is unclear to me. 3.1.4 did not offer any particular "please fix Poseidon for me" feature.

Poseidon sources are available, I don't see what would disallow you to fix things "properly" if you so wish.
One word: Time. Poseidon sources for AROS are available, which do not compile on a 68K classic system. Poseidon sources for 68K are licensed by iComp, and from there I'll try to arrange an update. But anyhow, you can certainly try to be helpful and fix this in the AROS branch.
 
The following users thanked this post: Tygre

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #588 on: August 14, 2019, 03:36:09 PM »
You keep talking about keyboards while all my issues with input.device and Poseidon were related to mouse.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #589 on: August 14, 2019, 03:42:44 PM »
Just to clarify, the MuForce hit I posted recently was for when deleting files from RAM disk.   
The RAM disk file deletion itself is fine, so I can only assume that something broke before this point and damaged the data structures of RAM: MuGuardianAngel may be able to detect this problem. BTW, in case the machine seems to hang when you run it: This is normal. What it does during startup is to fill the free RAM with a "magic cookie" and depending on the size of the RAM, this may take quite a while. So give it some time. Also, you will notice that the system is considerably slower when it runs. This is also normal and due to the RAM checks.

For multiview (seperate issue), I haven't been able to get anything that makes sense from MuForce.   But there is still 1 thing that is different:

1) v40.8 (3.1) --> this is opening screen that is larger than the picture size (no issue)
2) v45.9  (3.9) -> this is opening screen that is larger than the picture size (no issue)
3) v45.22  (3.1.4) --> this one is scaling screen to match picture size (see graphic corruption and memory corruption).   Also, as noted previously, the other side affect is if the picture is very small then the menu/ASL requester cannot show on the very small screen.

Can it be something to do with the screen size change that is happening in v45.22?
The picture datatype is able to scale pictures. In case you have trouble with this function, I would need the original picture size, and the size you scaled it to, which would allow me to reproduce the issue.

Thanks,
Thomas


Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #590 on: August 14, 2019, 03:50:34 PM »
You keep talking about keyboards while all my issues with input.device and Poseidon were related to mouse.
Not that I'm aware of, but then again, I'm not using Poseidon. So what is the issue with the mouse?
 

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #591 on: August 14, 2019, 07:31:13 PM »
You keep talking about keyboards while all my issues with input.device and Poseidon were related to mouse.
Not that I'm aware of, but then again, I'm not using Poseidon. So what is the issue with the mouse?

Like I wrote... a particular problem I have with original input.device, is that I cannot click on links in IBrowse using USB mouse, as if IBrowse doesn't get the "mouse-button release" event properly. I also recall problems with other programs (DOpus Magellan among them), but I don't recall exactly how the problems manifest themselves in the various programs. Because with input.device v50, these problems are not there.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #592 on: August 14, 2019, 10:43:52 PM »
Like I wrote... a particular problem I have with original input.device, is that I cannot click on links in IBrowse using USB mouse, as if IBrowse doesn't get the "mouse-button release" event properly. I also recall problems with other programs (DOpus Magellan among them), but I don't recall exactly how the problems manifest themselves in the various programs. Because with input.device v50, these problems are not there.
Ok, I understand. Maybe. What I do not understand is that the input device, no matter which revision, will not generate key-up events itself. Thus, if Poseidon does not feed key-up events (or rather "button-up" events), they will not appear on the input event chain, no matter which version of the device you are using. What is different is that sending events down the handler chain does not update the keyboard qualifier. Thus, if a software attempts to learn about the pressed "qualifier keys" by PeekQualifier(), then this will not work for synthetic events. However, software should really not depend on PeekQualifier() in first place (see the docs, this is what the input device "thinks" the qualifiers to be, not naturally what they *are*). Instead, software should use the qualifier information from the event (or equivalent IDCMP message) where we do have reliable information.

Thus, at this point, this looks like an implementation defect  at DOpus attempting to obtain qualifiers in an unreliable way. PeekQualifier() is not as useful as one may think, and it certainly should not be called to obtain keyboard or mouse button state information.
« Last Edit: August 15, 2019, 05:05:32 AM by Thomas Richter »
 
The following users thanked this post: Tygre

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #593 on: August 15, 2019, 06:05:13 AM »
For multiview (seperate issue), I haven't been able to get anything that makes sense from MuForce.   But there is still 1 thing that is different:

1) v40.8 (3.1) --> this is opening screen that is larger than the picture size (no issue)
2) v45.9  (3.9) -> this is opening screen that is larger than the picture size (no issue)
3) v45.22  (3.1.4) --> this one is scaling screen to match picture size (see graphic corruption and memory corruption).   Also, as noted previously, the other side affect is if the picture is very small then the menu/ASL requester cannot show on the very small screen.

Can it be something to do with the screen size change that is happening in v45.22?

I am unclear what you mean by "this is openening screen".


Multiview has a menu item for using a "separate screen".   Initially, when I load the picture, the picture is displayed in a window on workbench.   I then use the "separate screen" menu option.  Multiview then opens a new screen.   The screen that opens for v45.22 is always exactly the same as the picture size.   So for instance if the picture is 200x100 pixels, the screen would be that same size.    In the other multiview versions, the picture is still displayed in 200x100 pixels but the screen itself could be 668x472.  The pixels that are not part of the picture are displayed black.  In the other multiview versions I can move the mouse pointer beyond the picture size into the black space.  For 45.22, I cannot (hence reason I'm thinking the screen size itself has been sized to same as picture).

I'm attaching a few MuGuardianAngel dump -- thanks for letting me know that it takes time to boot.   I actually started to see something during boot itself but this is something else and not related to multiview.  The other 2 attachments are 2 times that I got multiview to crash.   Strange thing is that with MuGardianAngel enabled, the graphic corruption doesn't happen right away.  And only happens if I start clicking or try to open an ASL requester, and then I see issue.

 

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #594 on: August 15, 2019, 06:34:59 AM »
Like I wrote... a particular problem I have with original input.device, is that I cannot click on links in IBrowse using USB mouse, as if IBrowse doesn't get the "mouse-button release" event properly. I also recall problems with other programs (DOpus Magellan among them), but I don't recall exactly how the problems manifest themselves in the various programs. Because with input.device v50, these problems are not there.
Ok, I understand. Maybe. What I do not understand...
Quote
Why Chris did not do that is unclear to me.

So it looks like you don't really understand what input.device v50 "cludges" to make things work.

USB is a complex mess, with at least two protocols just for the mouse (bootmouse and hid) and ditto for keyboard, and lots of products in the market that break these protocols in various creative ways. Chris was very clear that using v50 input.device from MorphOS was only a half-way and quick solution for him, and that the entire input system for AmigaOS should have to be rewritten.

Quote
Thus, at this point, this looks like an implementation defect  at DOpus
DOpus, IBrowse, various other MUI software and whatever else that misbehaves with original input.device and Poseidon - you are now the one speculating ... educated speculation, but speculation nevertheless.

For DOpus it is easy enough to look for PeekQualifier in the code... I am not convinced that it is used in parts of the code relevant to where I experience trouble...

https://github.com/mheyer32/dopus5allamigas/search?q=PeekQualifier&unscoped_q=PeekQualifier

You also wrote...
Quote
All I can say is that I took precautions to address the problem, and I did my best to provide a solution.
yet...
Quote
The input device of 3.1.4 is the same as that of 3.1, and the only new thing it added was NSD. It does not provide any better solution than 3.1, but as of 3.1, there was already a correct way of doing it, namely create synthetic keyboard events yourself for keyboard repeat.
This is confusing. Unless the precaution was to not change anything, and to define "the problem" as non-existent.

Anyways - the best advice - as of now - for anyone using Poseidon with USB keyboard and/or mouse - is to load input.device v50 using LoadModule.
« Last Edit: August 15, 2019, 06:43:43 AM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #595 on: August 15, 2019, 03:48:52 PM »
So it looks like you don't really understand what input.device v50 "cludges" to make things work.

USB is a complex mess, with at least two protocols just for the mouse (bootmouse and hid) and ditto for keyboard, and lots of products in the market that break these protocols in various creative ways. Chris was very clear that using v50 input.device from MorphOS was only a half-way and quick solution for him, and that the entire input system for AmigaOS should have to be rewritten.
USB might be a mess, but that mess is the responsibility of the hid.class and not of the input.device. It is up to the hid.class to create the right events and feed them to the system. If it does not do that, the system will misbehave. It is not the job of the input.device to fix inconsistent input.

Quote
Thus, at this point, this looks like an implementation defect  at DOpus
DOpus, IBrowse, various other MUI software and whatever else that misbehaves with original input.device and Poseidon - you are now the one speculating ... educated speculation, but speculation nevertheless.
Not quite so. The only difference as far as Poseidon is concerned, and yes, I did have a look at the 68K sources -before you ask- is that it uses IND_ADDEVENT vs. IND_WRITEEVENT for submitting events to the input device, and the only difference on the side of the input.device is that IND_ADDEVENT creates synthetic keyboard repeat events and updates the qualifier mask for PeekQualifier().


yet...
Quote
The input device of 3.1.4 is the same as that of 3.1, and the only new thing it added was NSD. It does not provide any better solution than 3.1, but as of 3.1, there was already a correct way of doing it, namely create synthetic keyboard events yourself for keyboard repeat.
This is confusing. Unless the precaution was to not change anything, and to define "the problem" as non-existent.
The precautions do not address 3.1.4 in any way. This is for 3.2 and beyond. Loading another input.device because the hid.class does only half of its job, and applications are uncareful about qualifier masks is rather a workaround than a fix. I do not know Chris' motivation, but maybe he wasn't willing to create branches of his code to address interface changes that appeared in Morphos. The original input.device as such has a reasonably well-defined interface.

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #596 on: August 15, 2019, 03:52:11 PM »
Multiview has a menu item for using a "separate screen".   Initially, when I load the picture, the picture is displayed in a window on workbench.   I then use the "separate screen" menu option.  Multiview then opens a new screen.   The screen that opens for v45.22 is always exactly the same as the picture size.   So for instance if the picture is 200x100 pixels, the screen would be that same size.    In the other multiview versions, the picture is still displayed in 200x100 pixels but the screen itself could be 668x472.  The pixels that are not part of the picture are displayed black.  In the other multiview versions I can move the mouse pointer beyond the picture size into the black space.  For 45.22, I cannot (hence reason I'm thinking the screen size itself has been sized to same as picture).
Thank you for the logs, I'll have a look as soon as I am back home. Yes, multiview opens the screen the same size of the picture, that is correct. I wonder why that would be a problem? Do you use RTG graphics or FBlit in your system? For which picture size does the problem appear?

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #597 on: August 16, 2019, 04:42:01 AM »

Thank you for the logs, I'll have a look as soon as I am back home. Yes, multiview opens the screen the same size of the picture, that is correct. I wonder why that would be a problem?

Do you use RTG graphics or FBlit in your system? For which picture size does the problem appear?
I'm using the Amiga native graphics and not using any hacks (no FBlit or anything). For the #?.bmp files, I've only checked a handful and can't see there is any particular size causing the issue.  I actually compared the picture on my monitor with both v45.22 and earlier Multiview versions and the picture itself is exactly the same x and y size in all versions.  There is no scaling going on between the versions.  In v45.22 where I see graphic corruption, it seems like certain pixels of the picture get overwritten.

I've tried all kinds of IFF sizes and those load just fine.   However, if the IFF picture is small there is a secondary problem with the small screen size -- title bar could be not long enough to show all menus and if you do use the Open ASL, the ASL won't be opened because there is no space on the screen. 
 

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #598 on: August 16, 2019, 12:14:19 PM »
the ASL won't be opened because there is no space on the screen.

Imagine if it was possible to open a window larger than screen, and move it around with a qualifier + left mouse button pressed...
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #599 on: August 16, 2019, 08:05:44 PM »
I'm using the Amiga native graphics and not using any hacks (no FBlit or anything). For the #?.bmp files, I've only checked a handful and can't see there is any particular size causing the issue.
Thanks, I received the images and I'll check them - I'm now on my way home.