jesperstarkar
commented
7 years ago I can confirm this
Closed k4kfh closed 6 years ago
jesperstarkar
commented
7 years ago I can confirm this
Julusian
commented
7 years ago The relevant section of code has been disabled. Looks to be as the way it was working in 2.0.7 isn't linux compatible. https://github.com/CasparCG/Server/blob/2.1.0/modules/screen/consumer/screen_consumer.cpp#L200 Fixing this on windows would be simple, but linux doesnt appear to have an alternate api to use.
It might be best to 'fix' this by implementing https://github.com/CasparCG/Server/issues/487 and removing the option for device selection, unless it is ok for that to be windows only.
k4kfh
commented
7 years ago I dont fully understand #487 but from what I read I think for simplicity's sake I would rather the device selection thing be Windows only.
Also, this is weird, but yesterday when I tried the 2.1.0 Betas on my laptop, it seemed to handle device selection okay. I can do more detailed tests and determine if it's a hardware incompatibility issue, but that struck me as strange...
Julusian
commented
7 years ago I can understand that it is much nicer to be able to specify screen number, unless more control is desired.
I don't see how it could have worked, in the code it is hardcoded to the primary screen.
k4kfh
commented
7 years ago Never mind, my bad. I had a handful of different builds in my downloads from trying to solve this issue, and the one that worked was the 2.0.7 beta (not even sure how I ended up with that, but oh well)
On could both platforms support the x/y option and then have device as a nice bonus on Windows only? That might be a happy medium. Although personally I am in favor of whatever solves this issue quickest.
Julusian
commented
7 years ago https://drive.google.com/open?id=0B4xCe4AF2PEUczhZU3dETERDdUE https://github.com/CasparCG/Server/pull/620
I haven't tested this, but the code is the same as 2.0.7 so don't see why it wouldn't work.
k4kfh
commented
7 years ago Yup, you're right, that behaves as it should. Thank you!!!! You are a lifesaver.
Perhaps we should at least make a note on the Wiki page where it discusses the screen consumer? I understand this is kind of a strange problem to solve but for people who don't care about Linux support in their fleet, it would be super nice to have a "hey, FYI, this is a weird problem but if you just run Windows machines you can use this fix".
Julusian
commented
7 years ago Good point, I meant to add some docs but forgot. I dont feel the wiki should be updated just yet, that should be done once merged into main caspar. I have added logging though, so if someone does try that setting on linux they will get a warning in their logfile
k4kfh
commented
7 years ago Okay. Is there a separate place for docs for the beta releases? Or even some release notes on GitHub? I understand maybe it's not worth the overhead to maintain separate docs for the Betas, but having a simple Markdown file of things to be aware of would be really awesome.
I would be happy to help get a notes sheet like this started. We could link it on the website underneath the Beta 1/Beta 2 links, or even just bundle it as a TXT file in each build, whichever is easier.
Julusian
commented
7 years ago There is a seperate wiki page for the 2.1 protocol, but not configuration. The config file is self documenting, and the latest revision of my changes have added a note there.
Doing anything more would need to be discussed with the maintainer for it to be effective, which would have to wait until that role is filled.
k4kfh
commented
7 years ago Okay. Bad news, in my initial test the fix you did worked, but when I changed the config file from <windowed>false</windowed> to <windowed>true</windowed> it launches on the primary display regardless.
k4kfh
commented
7 years ago I believe I found the offending code. It appears to only set the position of the window if it's windowed, not if it's fullscreened.
https://github.com/CasparCG/Server/blob/2.1.0/modules/screen/consumer/screen_consumer.cpp#L243
if (config_.windowed)
{
window_.setPosition(sf::Vector2i(screen_x_, screen_y_));
window_.setSize(sf::Vector2u(screen_width_, screen_height_));
}
else
{
screen_width_ = window_.getSize().x;
screen_height_ = window_.getSize().y;
}Going to try and fix this myself but I am not an experienced C++ dev so if you're not busy help is appreciated haha
Julusian
commented
7 years ago Try this version: https://drive.google.com/open?id=0B4xCe4AF2PEUYVZzc2J1OHI4Q0E
Annoyingly my test machine doesnt want to work with multiple screens properly, so I am unable to test this myself easily..
k4kfh
commented
7 years ago We're moving in the right direction, as that one launches on the right screen in fullscreen mode, but it uses the wrong aspect ratio and everything is squished around funny. Aspect ratio is behaving as expected if I use windowed mode though. Maybe just fullscreen it on your main display so you can see what I mean?
And I don't know if it's important, but in the version on GitHub right now there's an #include statement commented out at the top of the file.
Julusian
commented
7 years ago So I've had a play, and it appears to be an issue with a library being used. That library was upgraded for 2.1. I have manually specified some positions for the window to be created, and it seems to be limited to the primary screen. If it spills over the edge of the screen, it gets snapped back to the top left. If it it inside the second screen, then it stays in the first screen, but with the expected offset applied (so what should be 100px from the left of screen 2 is 100px from the left of screen 1) I'm going to keep playing, and maybe see how an even newer version of that library behaves, as that version is from 2014 and there are a few newer releases.
Julusian
commented
7 years ago About the aspect ratio, I am getting the behaviour I would expect. Could you elaborate on what you mean?
k4kfh
commented
7 years ago Alright, what library? Just curious cause I might play with it a little myself.
The aspect ratio is hard to describe. A picture is worth a thousand words.
I set the consumer to 720p and it does that when I fullscreen it. In windowed mode, the ratio is normal, but when fullscreened it doesn't like the right side of the screen for some reason.
Thanks again for your help.
Julusian
commented
7 years ago The library is SFML. Caspar 2.1 is using SFML v2.2 and Caspar 2.0 is using SFML v1.6.
I've just had a test with 2.0 and I am having the same issue positioning in windowed mode, so this isn't something new.
What resolution are the screens on your machine? Im wondering if it is getting sizes or apect ratios confused
k4kfh
commented
7 years ago It's a Dell Precision M4500 with an extra monitor. The internal display is 1366x768 (16:9) and the external display is 1280x1024 (4:3).
On Sun, Aug 20, 2017 at 4:55 PM, Julian notifications@github.com wrote:
The library is SFML. Caspar 2.1 is using SFML v2.2 and Caspar 2.0 is using SFML v1.6.
I've just had a test with 2.0 and I am having the same issue positioning in windowed mode, so this isn't something new.
What resolution are the screens on your machine? Im wondering if it is getting sizes or apect ratios confused
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/CasparCG/Server/issues/619#issuecomment-323614520, or mute the thread https://github.com/notifications/unsubscribe-auth/AKNEh4d8mwm7vrzL2X9GZs12s3e_1s8tks5saKtVgaJpZM4O8Iua .
Julusian
commented
7 years ago https://drive.google.com/open?id=0B4xCe4AF2PEUUDFteV9tZnBEZms
OK, so the aspect ratio issue was down to it using the info from the wrong screen. It was introduced by a commit again https://github.com/CasparCG/Server/issues/495, which is one of yours. Was that one fixed? If so, could you check if it is still ok in this build?
The position issue has been 'fixed' by removing the close button from the window. I dont understand why that would be the cause, and is a little annoying as sceen consumers are now harder to remove.
k4kfh
commented
7 years ago I'm pretty sure that commit fixed my issue. The machine I was experiencing that on had some really wacky monitor resolutions, and I don't currently have access to it to test, but I have never experienced that problem on my laptop with its differing monitor resolutions. Either way, regardless of whether or not it's fixed, the installs I am managing now have all matching resolutions so it's more important to me to fix the monitor selection issue.
I'll test the latest one when I get home and let you know. Thanks again!
Side note: do I just need Visual Studio to tinker with this myself? I've really only developed with scripting languages up to this point and don't have any formal programming education but I'd like to have an environment to tinker with CasparCG in.
On Sunday, August 20, 2017 at 5:37 PM Julian notifications@github.com wrote:
https://drive.google.com/open?id=0B4xCe4AF2PEUUDFteV9tZnBEZms
OK, so the aspect ratio issue was down to it using the info from the wrong screen. It was introduced by a commit again #495, which is one of yours. Was that one fixed? If so, could you check if it is still ok in this build?
The position issue has been 'fixed' by removing the close button from the window. I dont understand why that would be the cause, and is a little annoying as sceen consumers are now harder to remove.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Julusian
commented
7 years ago OK great.
Yes, you do need visual studio to do that. Everything you need is free and https://raw.githubusercontent.com/CasparCG/Server/2.1.0/BUILDING should explain everything you need to do so
k4kfh
commented
7 years ago Yup, that latest build you published does exactly what I need. Thank you so much!!! Did you end up swapping SFML out for a newer version, or did you only have to remove the close button? And do you mind sending me the source?
@jesperstarkar See this link for a build by @Julusian that fixes this issue if you need it.
So I guess I should leave this issue open to see about getting these changes merged into the main branch? Or should I go ahead and close?
Julusian
commented
7 years ago I only had to remove the close button, upgrading SFML would have meant a bunch of changes elsewhere as its api has breaking changes. The final changes are at https://github.com/Julusian/CasparCG-Server/commit/ebccf21e08a2b87235b59e8fa18e362dc34e834a
I think it might be best to leave it open to make it easier for anyone to find if they are having the same issue. Once the changes have been merged it can be closed.
mauricev78
commented
7 years ago I hope this will be merged soon it will help me out on a paticular job
ls
k4kfh
commented
7 years ago @mauricev78 If you need this feature I would recommend using the build linked in this thread. Don't wait on it to merge. CasparCG as a project appears to be a little bit in limbo right now as SVT tries to find a new full-time maintainer (notice there have been no new commits since April 24th). You may already know this but when I made this issue I did not, so just be aware. Thanks.
mauricev78
commented
7 years ago thanks k4kfh
@Julusian although this is nice how hard/easy is it to implement #487
Julusian
commented
7 years ago It would be fairly straightforward to do, there isn't really any complex logic to add beyond figuring out how the options should interact, which I shall post about in #487 so that they can be discussed properly.
ronag
commented
6 years ago
In the 2.1.0 beta (and any builds in the 2.1.0 tree that I've tried) it seems the screen consumer ignores the
<device>directive. Regardless of what number I put in, the consumer launches on the primary display. 2.0.7 works perfectly with the same configuration, so not really sure what's going on.Here's a log: