Anyone here working on the current swift on freebsd effort?

Not I.

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

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

GoSox on plain console? or on X?

in any gui, KDE, XFCE4

likely issue with X config unless the monitor does not support anything else;)

GoSox, I would ask what display adaptor you have and what resolutions does xrandr say is available?

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

display adaptor meaning video card?

and xrandr lists all common resolutions you’d expect on a 1080p display

pciconf -lv | grep -B 3 -A 1 display

vendor = 'Intel Corporation'

device = '3rd Gen Core processor Graphics Controller'

class = display

subclass = VGA

not sure why it says VGA, its an HDMI/DVI physical connection

That's the Intel graphics and it should be very well supported. Hmm...

yeah its an intel HD 4000 in a 2012 mac mini

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.

gotcha

How are you selecting other resolutions? Using xrandr?

tried with xrandr and tried in the gui, both give me unusable distorted video

And by smaller than Full HD (1920x1080) you mean something like 1024x768, right? In order to make fonts bigger overall?

ideally 1280 x 720 and yes i know about the scale setting but actually changing the resolution would be better

I do that on a 1080 laptop myself. I deres it to 1400x900 to make the fonts just a little bigger and more readable.

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

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

so either way, 720p would be ideal

Hmm... Could it be a bad combination with the monitor? Maybe try a different display with it?

but it works perfectly in every resolution in macos

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.

thats true

but i still could use it now for useability

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.

But if you are planning VNC later then you might as well get used to doing it now.

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

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.

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

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

i have tried to recreate that magic but it won’t do it

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.

unfortunately this is the only spare display i have

Even for a temporary test?

Anyway... Good luck! It is way past too late to be awake here. Good night all!

well, i suppose i could bring the mini downstairs nad hook it up to the tv

probably not tonight though

hdmi connection?

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

i am using the mini’s hdmi port with an hdmi to dvi adapter

its not just small fonts, its small everything. I’m sitting far from the machine, i need a lower resolution

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

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

it may be problem about software handling the hdmi-dvi, might want to test DVI output using Mini DisplayPort to DVI Adapter

if only i had one

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

amazon seems to sell those adapters like for 10€ :)

(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)

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?

i think so but i can recheck right now

well thats not good, the computer seems to be frozen

at 3:20

my ssh link is still working fine but the GUI seems locked except for cursor movement

so 720 is still broken

Nothing under 720p is working either

btw this is what 720p gives me:

hmm not sure if you have to be logged in to see that or not

that looks like monitor is still in 1080p and attempting to use 720p signal

just checked the monitor mid switch and it is getting a 720p 60 signal

yes, but the image is "mirrored", so either the same pixels are drawn again or two lines ares concatenated ...

it gets mirrored different amounts at different resolutions, but all are unreadable

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

standby i had shut it off, powering it back on now

that command returned nothing

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

things aren’t displaying too small, they’re displaying normal size for 1080p

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

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?

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

I think I got it working, thank you!

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

if a package patch (newer version) isn't merged for months, when is a 'maintainer timeout' happening?

if the maintainer doesn't respond for two weeks to a feedback request it is a maintainer timeout

there is this: bugs.freebsd.org/bugzilla/show_bug.cgi?id=292129

no step taken forward for months now ...

meanwhile I'm using my patch and just updated to reflect the latest package changes today

I've also offered to share maintainership, to no avail

seems more like the issue is bugs.freebsd.org/bugzilla/show_bug.cgi?id=292129#c4 as the first patch was provided by the maintainer

yes but we have provided plenty of patches that work, so he would just have to apply one and see if it builds

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

Sascha Biberhofer

see bugs.freebsd.org/bugzilla/show_bug.cgi?id=292129#c11

that is the maintainer, but not a commiter, so he can't commit that

who's the committer then?

there are several committers, they aren't assigned to any given port

then I'm kinda lost. whom do I need to pester to have the patch added so the package can be upgraded?

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?

packages for 14.3 should work fine on 14.4, and yes, kernel modules, e.g. video drivers would need rebuilt

ty rtprio

Following the Rust port discussion — is the committer gap for newer languages a known scaling problem, or considered acceptable?

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.

you should include output of uname -a and any related ports/packages you have installed