14:47:18 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! 15:23:34 [illumos-gate] 16514 xhci panic on pipe open failure -- Joshua M. Clulow 15:23:34 [illumos-gate] 16515 xhci should unconfigure periodic endpoints to release bandwidth -- Joshua M. Clulow 15:41:35 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. 16:17:21 jclulow: Ok, thank you. 16:58:14 Aedil: At a glance, I suspect uts/common/io/mouse8042.c is probably part of the kernel machinery for PS/2 mouses 17:34:35 jclulow: Ok. Sadly I am no C systems programmer. 18:34:55 jclulow: there's that file, and vuidps* 18:56:24 speaking of vuid, less than 13 years left of mouse & kbd events: https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/vuid_event.h#L372 18:57:56 alanc: I still have somewhere in my todo list removing the vuid for things that just can't be (like, say, bus mice) 18:58:35 I'm sure someone could have fun working out whether virtualized ps/2 tends to be "two button" or "three button" too 19:00:59 I thought garrett already did that: https://github.com/illumos/illumos-gate/commit/57f4a14abf7408570afb91750e10e4b57f721549 19:01:00 → GitHub commit 57f4a14: PSARC 2009/334 EOF of legacy bus mice PSARC 2009/341 remove (committed) 19:04:13 though I do love the random sprinklings of SunView & SunwWindows references left in the vuid code 19:08:33 alanc: vuidm[345]p.c 19:10:14 oh, I don't remember what those are for 20:53:42 vuid sounds vaguely familiar haha 20:54:57 I guess I'm thinking of the firm_event stuff 20:56:16 I have code in some projects that take keyboard input and draw to the framebuffer that uses KIOCGDIRECT and reads struct firm_events out 21:14:47 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? 21:17:41 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 21:21:13 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. 21:21:19 I get "Unable to change permitted privilege set: Insufficient privileges" on Solaris. 21:21:29 and "Unable to change permitted privilege set: Not owner" on illumos. 21:24:35 It's error 1, so EPERM. 21:25:30 Are the illumos strerror strings intentinally obtuse? 21:34:44 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 21:34:44 (i.e. blocking the other kthreads on the queue of this STREAMS modules)? How is this handled? 21:40:06 jhj Apparently it is historical and never fixed in illumos. 21:41:42 twobitsahead streams or not, but if you get yourself sleeping while holding a mutex, you will have some friends waiting for you.... 21:42:26 tsoome: I just had someone mention to me that "my error messages are useless!" so ... :) 21:44:14 yes, you can tell it has been so for last 30 or 40 years, I guess;) 21:44:15 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 21:44:56 jhj from serious side, it is probably good idea to fix it. 21:45:07 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? 21:45:08 and generally interrupt handlers are going to be very careful about the locks it acquires (if any) 21:45:48 andif you take locks at high they exclusively spin, there is no sleeping 21:45:57 "high priority" 21:46:02 richlowe "Operation not permitted" seems to be better response for EPERM ;) 21:46:09 richlowe: Yes, this is just strerror's messages, so I'm assuming that Solaris must have obtained "better" messages somewhere along the way. 21:46:31 at least, thats what the rest of the world seems to think;) 21:46:56 AIX uses short novels. 21:47:20 "There was insufficient memory when the operation was attempted." 21:47:28 etc. 21:47:38 tsoome: Yes, our having exposed the damn naked data sure does suck 21:47:39 They bother me immensely because they end in punctuation, and nobody else does. 21:47:43 Thanks, I wanted to be sure I understood things correctly 21:47:50 visible global data, just say no 21:51:30 Actually, the longer AIX error messages like that are the 'localized' ones you get from strerror_l and friends, I think. But anyway. 22:00:17 richlowe: Here are the differences from Solaris vs. illumos: https://dpaste.com/GANRCPKBM.txt 22:15:40 @jhj cool read. I find those to be more readable, as well 22:16:38 https://github.com/illumos/illumos-gate/blob/113ae9130ee83ef358c36cc3521d4a55e3e9da00/usr/src/lib/libc/port/gen/errlist has an exciting note. 22:16:40 * WARNING! 22:16:40 * Do NOT add or modify entries to this list before the end of legacy 22:16:40 * entries marker. Amending this list may damage programs because data 22:16:40 * is copied into reserved arrays at runtime. See bug 4097669. 22:17:18 I wonder if amend means "don't even change the text"? 22:18:51 Regardless, I've passed the user complaint upstream now, thanks for listening. :) 22:25:40 Triton Product Security announcement TPS-2025-002 : Debian 12 LX zone image from 2024-07 has static SSH keys. 22:25:40 https://security.tritondatacenter.com/tps-2025-002/ 22:25:40 This affects SmartOS and OmniOS aswell. 22:26:28 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 23:10:11 hmm, looks like the "or modify" part of that warning is a recent illumos addition that was never in Solaris or OpenSolaris: https://github.com/illumos/illumos-gate/commit/e4e529b2beb8a30e14beb0573c4a114275d157cc#diff-a3f05ff003b2f47b8c31c0d1e5221bc425a5779d84390e2f8308968d0b61a61b 23:11:34 Solaris has filled in some blanks in the list, but not grown it past errno 151 23:12:29 we also resynced it so that list, Intro(2), and errno.h use the same descriptions, as well as improving some of the descriptions 23:20:44 So the Solaris error messages should match those listed on https://docs.oracle.com/cd/E88353_01/html/E37841/intro-2.html now 23:30:16 as noted in https://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 23:30:17 → OpenSolaris issue 4097669: add checks to keep sys_errlist from growing (Fix Delivered) 23:30:53 (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) 23:38:25 and have decided to seriously inconvenience users haha 23:38:55 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 23:44:34 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. 23:44:51 well, you've got a bit under 13 years to either do that or add "large time" API's to 32-bit libc 23:46:02 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 23:47:36 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 23:49:48 There are ways we can improve it for new software and have already started doing so.