03:34:22 Anyone here working on the current swift on freebsd effort? 06:35:34 Not I. 06:36:53 no but i made a php script to calculate pi by simulating the “dart throwing method”, but using a large perfect grid rather than random dart throws 06:41:35 anyone have any more ideas i can try regarding my display resolution problem? The native 1080p resolution works but anything smaller and the monitor freaks out and i get no useable video, just scrambled interlaced artifacts 07:13:26 GoSox on plain console? or on X? 07:13:55 in any gui, KDE, XFCE4 07:17:31 likely issue with X config unless the monitor does not support anything else;) 07:17:56 GoSox, I would ask what display adaptor you have and what resolutions does xrandr say is available? 07:18:04 this is on a mac mini, in macos it supports all common resolutions just fine. but on freebsd and even in ubuntu linux, it only supports full native 1080p 07:18:21 display adaptor meaning video card? 07:18:35 and xrandr lists all common resolutions you’d expect on a 1080p display 07:18:45 pciconf -lv | grep -B 3 -A 1 display 07:19:25 vendor = 'Intel Corporation' 07:19:25 device = '3rd Gen Core processor Graphics Controller' 07:19:26 class = display 07:19:27 subclass = VGA 07:19:41 not sure why it says VGA, its an HDMI/DVI physical connection 07:19:43 That's the Intel graphics and it should be very well supported. Hmm... 07:19:55 yeah its an intel HD 4000 in a 2012 mac mini 07:20:16 That subclass is, I believe, historical now and it was VGA and continues to report it that way. Even though you are using digital modes now. 07:20:33 gotcha 07:22:39 How are you selecting other resolutions? Using xrandr? 07:23:08 tried with xrandr and tried in the gui, both give me unusable distorted video 07:23:43 And by smaller than Full HD (1920x1080) you mean something like 1024x768, right? In order to make fonts bigger overall? 07:24:12 ideally 1280 x 720 and yes i know about the scale setting but actually changing the resolution would be better 07:24:56 I do that on a 1080 laptop myself. I deres it to 1400x900 to make the fonts just a little bigger and more readable. 07:25:52 this is on a test machine using my spare monitor, and the space monitor is on a vesa arm that far back on my desk so i’m much furthe away from it than a normal display 07:26:26 HOWEVER once this is running on my real collocated server, i’m still going to want to use 1280 x 720 so when i VNC in from time to time, it will fit nicely on a window on my primary computer 07:26:33 so either way, 720p would be ideal 07:26:46 Hmm... Could it be a bad combination with the monitor? Maybe try a different display with it? 07:27:03 but it works perfectly in every resolution in macos 07:27:10 And if you are planning VNC later then it won't matter there. That's all virtual display there. So it won't be freaking out for you. Just do that now. 07:27:26 thats true 07:27:37 but i still could use it now for useability 07:27:49 And I know we had this conversation before but IMNHO servers should be headless. But we can agree to disagree. But all of my servers are headless. 07:28:15 But if you are planning VNC later then you might as well get used to doing it now. 07:28:38 well then you really won’t like how i went from the “light weight” xfce4 to the “heavy” KDE, with some simple customizing, i’m finding KDE to be REALLY nice 07:29:51 I have run KDE on my desktop. That was forever ago though. Haven't run it since then. It's an okay desktop. But not needed on a server. 07:29:59 if macos does ok, then it *should not* be about cables/connections, but then again, one never knows;) it also could be something weird like firmware behaving differently on different OS'es 07:30:58 i believe at once point, i did get 720p working on freebsd with some desktop, probably xfce4. But i forget what i did. It was nothing crazy, it would have just been pushing buttons in the GUI display settings 07:31:09 i have tried to recreate that magic but it won’t do it 07:32:30 Displays communicate their resolution and sometimes that's buggy. The native 1080 resolution might be fully functional but the others not so much. MacOS might ignore the display tables and do its own thing. No idea. But the EDID might be wrong just on this display and another display might work. 07:33:04 unfortunately this is the only spare display i have 07:33:27 Even for a temporary test? 07:33:46 Anyway... Good luck! It is way past too late to be awake here. Good night all! 07:34:57 well, i suppose i could bring the mini downstairs nad hook it up to the tv 07:35:17 probably not tonight though 07:36:11 hdmi connection? 07:36:32 if it about fonts being to small, is the nativ resoulution a 96x96 dpi resoultion? if not, did you try making Xorg report the correct resolution in the core protocol (sadly not much programs support getting the correct dpi via the XRandR extension), xrandr lets you change the reported dpi and you can tell it to use the dpi from a monitor for that via --dpi 07:36:35 i am using the mini’s hdmi port with an hdmi to dvi adapter 07:37:06 its not just small fonts, its small everything. I’m sitting far from the machine, i need a lower resolution 07:37:25 also the scaling feature, does not work. If i zoom in, nothin ghappens. It WAS working in xfce4 but in KDE it does not zoom at all 07:37:44 but i don’t really want to use that anyway so unless its the same problem as the resolution, i don’t really care about fixing that 07:40:36 it may be problem about software handling the hdmi-dvi, might want to test DVI output using Mini DisplayPort to DVI Adapter 07:40:56 if only i had one 07:41:30 sounds like programs use a to low dpi and are to small because of that, well but not everything does support scaling with dpi, is there any program that uses qt for gui that you use? if so try running it with QT_USE_PHYSICAL_DPI=1 in the environment to see if that is better 07:42:42 amazon seems to sell those adapters like for 10€ :) 07:44:58 (yes, for some reason you have to opt-in into using the correct dpi on qt, instead of using the dpi value from the core X11 protocol, that only supports one dpi value, so it just is the default 96x96 dpi in most cases) 07:47:17 hm. interesting, one cable spec is telling: Resolution: VGA, XGA, SVGA, SXGA, UXGA and WUXGA HDTV: 480i, 576i, 480P, 576P, 1080i, 1080p -- but 720p is not listed there; have you tested with anything less than 720p? 07:47:46 i think so but i can recheck right now 07:48:20 well thats not good, the computer seems to be frozen 07:48:28 at 3:20 07:49:05 my ssh link is still working fine but the GUI seems locked except for cursor movement 07:53:54 so 720 is still broken 07:56:48 Nothing under 720p is working either 07:56:53 btw this is what 720p gives me: 07:56:57 https://forums.freebsd.org/attachments/720p-jpg.25670/ 07:57:12 hmm not sure if you have to be logged in to see that or not 07:59:28 that looks like monitor is still in 1080p and attempting to use 720p signal 08:00:37 just checked the monitor mid switch and it is getting a 720p 60 signal 08:03:54 yes, but the image is "mirrored", so either the same pixels are drawn again or two lines ares concatenated ... 08:07:49 it gets mirrored different amounts at different resolutions, but all are unreadable 08:12:37 could you at least try if setting the correct dpi solves your issue instead of debugging why your workaround is broken? you said the output gets reported as HDMI-3? so xrandr --dpi HDMI-3 that makes Xorg report the dpi of the monitor on that output, instead of 96x96 08:14:11 standby i had shut it off, powering it back on now 08:16:38 that command returned nothing 08:20:05 I don't think it should print anything, it makes the dpi value reported via the core X11 protocol into the value for the monitor behind that output, so if some program only reads that instead of the per monitor dpi values you can get via the XRandR extension, then it should now get the correct value instead of 96x96, try opening some program and see if it still displays to small 08:20:57 things aren’t displaying too small, they’re displaying normal size for 1080p 08:30:29 ah, the other issue with dpi, it doesn't include viewing distance, but still, are you sure the right dpi was used? If programs used the correct dpi values, then everything would stay the same size no matter the resolution 09:54:55 I could use some BSD make file help. I have a tool that produces several output files. Run it once and it produces A B and C, how do I tell make that if any one is missing run the tool but don't run it three times? 10:53:53 hm, a workaround would be having only the A target have the command and have the B and C targets depend on A, but be empty 10:54:13 I think I got it working, thank you! 10:56:59 ah, then A could get deleted, as make considers it an intermediate file, not sure if bsd make deletes intermediate files as soon as all targets needing them are up-to-date 14:57:34 if a package patch (newer version) isn't merged for months, when is a 'maintainer timeout' happening? 14:59:10 if the maintainer doesn't respond for two weeks to a feedback request it is a maintainer timeout 15:00:11 there is this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292129 15:00:28 no step taken forward for months now ... 15:01:04 meanwhile I'm using my patch and just updated to reflect the latest package changes today 15:02:16 I've also offered to share maintainership, to no avail 15:05:53 seems more like the issue is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292129#c4 as the first patch was provided by the maintainer 15:09:08 yes but we have provided plenty of patches that work, so he would just have to apply one and see if it builds 15:12:17 but who is "he" in your sentence? (oh, I linked the wrong comment, should have been comment 2 "Apparently there are no committers willing to work on the port with rust.") 15:12:42 Sascha Biberhofer 15:12:59 see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292129#c11 15:14:18 that is the maintainer, but not a commiter, so he can't commit that 15:14:35 who's the committer then? 15:20:45 there are several committers, they aren't assigned to any given port 15:25:59 then I'm kinda lost. whom do I need to pester to have the patch added so the package can be upgraded? 17:32:20 Hello, I'm looking for clarification on doing a binary update. There is a large warning about package compatibility when going to the next RELEASE, like for 14.3 to 14.4. Do packages built on 14.3 work on 14.4 and is it only the kernel modules that need to be built by hand? 17:35:21 packages for 14.3 should work fine on 14.4, and yes, kernel modules, e.g. video drivers would need rebuilt 17:35:57 ty rtprio 17:48:52 Following the Rust port discussion — is the committer gap for newer languages a known scaling problem, or considered acceptable? 20:21:32 karolyi - easiest way, file a bug report, include examples on how to repro and any fixes/patches you want. Things usually get fixed fast enough and the right committers get mailed. 20:22:34 you should include output of uname -a and any related ports/packages you have installed