Hi, I use PS/2 3-button mice through my KVM/qemu virtualization on my current OpenIndiana illumos guest. Since I own this installtion, four two years or more, the mouse wheel in Xorg MATE does not work. Can anybody give a hint, how to enable the mouse wheel on OI illumos? Thank you!

[illumos-gate] 16514 xhci panic on pipe open failure -- Joshua M. Clulow <josh⊙so>

[illumos-gate] 16515 xhci should unconfigure periodic endpoints to release bandwidth -- Joshua M. Clulow <josh⊙so>

Aedil: I'm not sure! I would probably first try to figure out if the driver is passing on the scroll wheel events but X11 is not interpreting them correctly. If it isn't passing them on, I guess I would look at the driver to see if it understands the mouse wheel events, etc, as it may need some changes to support that.

jclulow: Ok, thank you.

Aedil: At a glance, I suspect uts/common/io/mouse8042.c is probably part of the kernel machinery for PS/2 mouses

jclulow: Ok. Sadly I am no C systems programmer.

jclulow: there's that file, and vuidps*

speaking of vuid, less than 13 years left of mouse & kbd events: github.com/illumos/illumos-gate/blo…rc/uts/common/sys/vuid_event.h#L372

alanc: I still have somewhere in my todo list removing the vuid for things that just can't be (like, say, bus mice)

I'm sure someone could have fun working out whether virtualized ps/2 tends to be "two button" or "three button" too

I thought garrett already did that: illumos/illumos-gate 57f4a14

→ GitHub commit 57f4a14: PSARC 2009/334 EOF of legacy bus mice PSARC 2009/341 remove (committed)

though I do love the random sprinklings of SunView & SunwWindows references left in the vuid code

alanc: vuidm[345]p.c

oh, I don't remember what those are for

vuid sounds vaguely familiar haha

I guess I'm thinking of the firm_event stuff

I have code in some projects that take keyboard input and draw to the framebuffer that uses KIOCGDIRECT and reads struct firm_events out

alanc: this is a niche question, but my memory has failed me and I don't like it: Did the v880z or whatever do the "multi-seat" thing where you could give it two screens, mice, keyboards?

I don't remember if you could do that on V880z since I think it only had one slot for a single XVR-4000 board - as I recall with Xsun, you needed an independent graphics device for each seat, I don't think you could split/share a single framebuffer

Hi there guys, I have a quick question. I wrote some code that modifies privilege sets, and the error messages on illumos are sort of lacking compared to Solaris.

I get "Unable to change permitted privilege set: Insufficient privileges" on Solaris.

and "Unable to change permitted privilege set: Not owner" on illumos.

It's error 1, so EPERM.

Are the illumos strerror strings intentinally obtuse?

I was reading through kernel docs and had a thought that I haven't found a clear answer to. This question is specifically about mutexes and STREAMS modules. Suppose that a low priority kernel thread enters a STREAMS module, and immediately acquires a mutex. While holding the mutex, this low priority kthread is interrupted and sleeps. Would the now-sleeping low priority kthread still be holding the mutex

(i.e. blocking the other kthreads on the queue of this STREAMS modules)? How is this handled?

jhj Apparently it is historical and never fixed in illumos.

twobitsahead streams or not, but if you get yourself sleeping while holding a mutex, you will have some friends waiting for you....

tsoome: I just had someone mention to me that "my error messages are useless!" so ... :)

yes, you can tell it has been so for last 30 or 40 years, I guess;)

twobitsahead: if you have a lock, you have a lock until you release it. Sleeping with locks is generally bad, yes, it's up to the programmer not to

jhj from serious side, it is probably good idea to fix it.

tsoome, jhj: error message wise it's presumably just strerror(3C)? Did Solaris add a better errno, a better string, or just better code at the top level?

and generally interrupt handlers are going to be very careful about the locks it acquires (if any)

andif you take locks at high they exclusively spin, there is no sleeping

"high priority"

richlowe "Operation not permitted" seems to be better response for EPERM ;)

richlowe: Yes, this is just strerror's messages, so I'm assuming that Solaris must have obtained "better" messages somewhere along the way.

at least, thats what the rest of the world seems to think;)

AIX uses short novels.

"There was insufficient memory when the operation was attempted."

etc.

tsoome: Yes, our having exposed the damn naked data sure does suck

They bother me immensely because they end in punctuation, and nobody else does.

Thanks, I wanted to be sure I understood things correctly

visible global data, just say no

Actually, the longer AIX error messages like that are the 'localized' ones you get from strerror_l and friends, I think. But anyway.

richlowe: Here are the differences from Solaris vs. illumos: dpaste.com/GANRCPKBM.txt

@jhj cool read. I find those to be more readable, as well

github.com/illumos/illumos-gate/blo…0/usr/src/lib/libc/port/gen/errlist has an exciting note.

* WARNING!

* Do NOT add or modify entries to this list before the end of legacy

* entries marker. Amending this list may damage programs because data

* is copied into reserved arrays at runtime. See bug 4097669.

I wonder if amend means "don't even change the text"?

Regardless, I've passed the user complaint upstream now, thanks for listening. :)

Triton Product Security announcement TPS-2025-002 : Debian 12 LX zone image from 2024-07 has static SSH keys.

This affects SmartOS and OmniOS aswell.

I'm a little fish in a big pond. I can't disagree with having more informative errors. I checked out the link and now I'm curious as to what's going on here, as well

hmm, looks like the "or modify" part of that warning is a recent illumos addition that was never in Solaris or OpenSolaris: illumos/illumos-gate e4e529b#diff-a3f05ff003b2f47b8c31c0d1e5221bc425a5779d84390e2f8308968d0b61a61b

Solaris has filled in some blanks in the list, but not grown it past errno 151

we also resynced it so that list, Intro(2), and errno.h use the same descriptions, as well as improving some of the descriptions

So the Solaris error messages should match those listed on docs.oracle.com/cd/E88353_01/html/E37841/intro-2.html now

as noted in illumos.org/opensolaris/bugdb/bug.html#!4097669 the linking limitation on the number of errors in the sys_errlist array is only a problem in 32-bit where it was exposed as a fixed size global array in libc, and isn't a problem in 64-bit libc, so the easy answer there is just EOL 32-bit libc

→ OpenSolaris issue 4097669: add checks to keep sys_errlist from growing (Fix Delivered)

(well, easy once you've finished the LP64 conversion of all the programs in the illumos gate, which is a non-trivial amount of work)

and have decided to seriously inconvenience users haha

Obviously _eventually_ the existing 32-bit ABI will no longer be useful, but I don't feel like we are anywhere near that point now

you could also leave the 32-bit sys_errlist frozen while evolving the 64-bit version; new errors could be folded (to EINVAL :-P) when returning them to 32-bitland.

well, you've got a bit under 13 years to either do that or add "large time" API's to 32-bit libc

yeah, we could have easily used a value past the end of the list for our EADI errno (mismatch in the ADI tags in a pointer), since that's only possible in 64-bit pointers, but there's still enough gaps below 151 we didn't need to

and at the very slow rate new errno values are added, illumos probably won't fill all the gaps < 151 in your list before 2038 either

There are ways we can improve it for new software and have already started doing so.