The Os 3.1.4 Thread

[kolla]

Under what conditions does the new SetPatch replace shell with L:Shell-Seg and under what conditions does it not replace shell with L:Shell-Seg? Does it care about what version of shell that is already resident?

[kolla]

I found $? so unreliable that I simply dropped using it, and instead use the old 'if "$var" eq "${var}"'-trick, really wishing that non-existing variables could just expand to an empty string.

A shame that all these new features cannot really be used in distributed scripts anyways, since only a fraction of the systems out there may have the shell required.

[kolla]

That's how it goes when there's no official and publicly available bug tracker that users can compare bugs they find against. So unnecessary.

[kolla]

There is one. There is a support thread at the Hyperion web side right for that.

That is not a bug tracker - you don't know what a bug tracker is??

It takes a public bug tracker for _users_ to know what bugs are already _known_ and, potentially, addressed.

[kolla]

I have zero interest in reporting bugs that may or may not be already known, it's just too much hassle.

At least you could have a text file somewhere, listing a summary of all known bugs. How hard can it be to generate such a list from your internal bug tracker

[kolla]

So dumb sheep, that is what we are.

(Begs the question - what do dumb sheep need "advanced" CLI for.)

[kolla]

It is realy not my loss that you miss out on bug reports.

[kolla]

Googling kolla's sig brings out his interpretation of responsibility....

Yes, though it's much harder to spot now, due to it being my signature.

Right?

[kolla]

So how will next version of scsi.device be "rolled out"?
Part of free update 3.1.4.1.5 loaded with LoadModule? OS 3.2 as a new product, with new floppies and kickstart chips to buy?
Questions that nobody can answer?

[kolla]

Which input.device are you using? Poseidon comes with input.device backported from MorphOS (v50) to fix various issues with USB hidd and v40 input.device (multi-kbd/mouse support and more), so maybe you are using that?

[kolla]

was getting 1,638,400 with previous version

Really? That number looks way too, uhm... casual, to be real

[kolla]

this is not a bug fix, it is an extended interface.

Well, from users' perspective, that is rather irrelevant distinction.

For me, the particular "issue" is that with original input.device, I cannot click on links in IBrowse using USB mouse, as if IBrowse doesn't get the mouse-button release event properly... with input.device v50 it works. As apparently there is no interest in maintaining Poseidon for Amiga OS, and all development taking place for MorphOS and AROS.. perhaps I should just switch to anaiis for AmigaOS and see how that works.

Anyways - the point here was just to give a heads up to make my_pc_is_amiga, that when installing Poseidon, a different input.device may also have been installed.

[kolla]

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.

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 )

[kolla]

You keep talking about keyboards while all my issues with input.device and Poseidon were related to mouse.

[kolla]

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.

[kolla]

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...

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.

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...

All I can say is that I took precautions to address the problem, and I did my best to provide a solution.

yet...

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.