Retroarch: OSD messages after launching RetroArch

[meleu]

I was used to see these OSD messages when launching RetroArch:

Joystick Name #1 configured in port #0.
Joystick Name #2 configured in port #1.
Core remap file loaded.
... other possible messages ...

But now I only see this message:

100%: Joystick Name #2 configured in port #1

But if I have no joysticks plugged (keyboard only), I see this:

Core remap file loaded.
... other possible messages ...

I mean, when there's a joystick connected RetroArch shows only the last joystick related message and nothing more. Even if there are other messages to show. Looks like the joystick message is preventing other messages from being displayed.

Is it intentional?

P.S.: yeah. I noticed that when working on #4217 .

[meleu]

I think it was introduced when task_autodetect.c (recently moved from input/ to tasks/) stopped to use runloop_msg_queue_push() and started to use task->title = strdup(msg) (https://github.com/libretro/RetroArch/commit/305b2becbd6d9caff1ff2a014dd6ffa18b1447d8#commitcomment-20200012)

[twinaphex]

I don't really consider it important. Yes, it no longer goes through the runloop message loop, tasks have their own way to report OSD messages. That is what the current task-based auto config is now using.

[meleu]

@twinaphex the current way, preventing other OSD messages to get shown, is the desired behavior?

[twinaphex]

The main objective was turning autoconfig into a task, which we succeeded in doing. I dont' consider this 'consequence' important enough to look at until after 1.4.0. There's far more important stuff to be done for that release.

I don't consider it a bug, but I don't consider it to be 'desired' either. It's just a minor insignificant side issue that we can look into maybe at a later date.

[orbea]

@meleu Can you retest the current master and see how much of this you can still reproduce?

[Ryunam]

I can confirm that, with the latest code, controller autoconfig notifications do not overlap the others anymore.
Still, upon loading a core that has both a control remap file and a configuration override, RA only displays "Core remap file loaded", omitting entirely the "Configuration override loaded" message.

[twinaphex]

I don't even think we should show OSD messages for the things you mentioned. Honestly, every time we show an OSD message, it looks unprofessional.

So, in this case, no, I'm not spending any more effort on this, I think it's good enough right now as-is and we shouldn't spam the OSD with so many messages anyway for random overriding of configs.

[Ryunam]

I understand your point and I agree with a certain sensation of untidiness and clutter that stems from having so many OSD notifications coming up one after another. It is after all the same reason that led me to attempt an implementation of a toggle option to decide which messages to show or hide.

However I believe that, from a user perspective, having a visual cue of something like a configuration override or a control remap is always helpful. With RA covering so many systems, each with their settings to tweak accordingly, I find it extremely easy to forget that a remap or an override was created for that particular content and the notification acts as a very useful reminder.

[twinaphex]

It shouldn't be 'visual cued' with ugly OSD text at least, and definitely not on a per-game basis.

Sorry but I disagree, most users wouldn't even want to be notified of all this stuff, they simply expect things to work and not to get information overload with a lot of text being spammed across the screen, message after message. Best thing to do would be to show inside Quick Menu -> COntrols that an override is active and then allow users to remove that if they want to.

Anyway, I'm moving on. There is more pressing stuff to do for 1.4.0 than this stuff. I have to get my priorities straight since I don't have a surplus of programmers here doing stuff.

[twinaphex]

Last-ditch attempt -

https://github.com/libretro/RetroArch/commit/7dfd5625ab90784c68441de575165d306338bd6b

See if that fixes it. If it doesn't fix it, I don't know and I determine my time is better spent focusing on other things.

[orbea]

I agree with not showing some of the messages, but as discussed in PR https://github.com/libretro/RetroArch/pull/4354 maybe it might be a good idea to instead of allow hiding them, set them to off by default and allow users to enable them?

[meleu]

@twinaphex In #4217 when trying to make you accept those RetroAchievements messages I implemented a boolean option named video_message_verbosity (default is false). Maybe it can please the two types of users.

If you don't have time to look at the complete PR's diff but agree with this aproach, I can submit a separate PR with video_message_verbosity only. Is it reasonable?

[twinaphex]

Yet even more settings? As if we aren't getting criticized of having too many settings already.

[meleu]

I did this way exactly to avoid those kind of critics. I think it's a simpler approach than adding one boolean setting for each type of OSD message the user wants.

With what I am proposing the user only have the option to enable/disable the OSD verbosity.

It was an attempt to match what you and @leiradel suggested.

[twinaphex]

OK, how about you rebase @Ryunam's PR then so that it becomes part of your PR as well.

[meleu]

I'll try it tonight. Thanks! :-)

[meleu]

@twinaphex Just to make it clear and avoid unnecessary rework. Your suggestion is to adding the show/hide controller autoconfig notifications in that RetroAchievements PR (#4217), right?

[Ryunam]

Personally I agree with @fr500 on the matter. I fully understand the concerns raised on avoiding an abundance of options, however it seems to me that the user base of RA is typically split into two halves: those who cherish the project for its broad array of features and degree of customization and those who complain about it being overcomplicated. Most of the time, the latter feel that way because of a perceived lack of explanation around every nook and cranny, rather than because of having options in the first place.

In this case I feel that two different points are being mixed in the discussion:
1) the minor issue about some of the OSD messages overlapping each other, which has been partially addressed by @twinaphex already - and I'm very thankful for the dedication he's poured into solving this minor inconvenience even if it's clear there are other priorities and I fully respect that;
2) the topic that was being discussed originally on the libretro boards and then here with my recent PR #4354 , about giving the user individual control over which OSD notification should be shown or hidden.

With regards to 1, it is not a major issue by any means and I would gladly take a look at it personally and try to understand what is causing the overlapping between Core Remaps and Core Override notifications. With all due respect, having to outright remove the override and remap notifications seems like a big step backwards.
Speaking of 2, I believe having multiple options to pick from is always preferable as it is one of the elements that make RA stand out and a general toggle to control everything seems adverse to that principle. That being said, I'll be happy to help @meleu rebase PR #4354 and use video_message_verbosity if that is the final word.

[Ryunam]

I agree that using an icon would convey the presence of remaps or overrides without adding bloat. If you need help in designing an appropriate pic, I can happily try and whip something out.The only complication I'm thinking of is that every Menu Driver would need a different implementation and / or icon resolution.

On the other hand, a text label or an in-menu log would seem counter-intuitive to me, since users would be forced to enter the Menu, navigate to Settings->Input (or to Quick Menu->Controls) and only then ascertain that an override was actually loaded. Doesn't it defeat the purpose of having a notification in the first place?

Aside from remaps and overrides, I'd like to further clarify the reasoning behind my proposal of a toggle for each OSD string. The risks of referencing settings_t are perfectly clear, but in my opinion redirecting everything under a general verbosity option would be restrictive and would not address the original request of having exact control over what to display or not display.
Some questions then spring to mind: what makes a certain notification 'verbose' and others 'not verbose'? What about plugging in a non-autoconfigured controller for example, or the message that comes up when disconnecting it?

[orbea]

@meleu Is the original problem at least solved?

[meleu]

@Ryunam I am from the first group you mentioned: "those who cherish the project for its broad array of features and degree of customization". Also I like that visual cue you mentioned (OSD messages).

I don't know the details of how the RetroArch team works (who decides what) and I'm not sure if we can get a final word about using video_message_verbosity. But looking at the commits history @twinaphex seems to be the person that merge most of the PRs. That's why I'm trying to make as he suggests.

I'm a RetroAchievements enthusiast and I really would like to see the PR #4217 merged (see some useful retroachievements messages when launching a game that has achievements). I don't care if I need to enable a specific option to see those messages or if it is enabled by a general OSD verbosity toggle (to be honest I think it should be the default, but the discussion on my PR showed that this isn't a consensus). I just did that way (video_message_verbosity) in a hope to make the PR be merged.
[EDIT: I detailed why I think the cheevos messages useful [here](https://github.com/libretro/RetroArch/pull/4217#issuecomment-270281219)]

I submitted that PR about a month ago and I had no hope to see it merged anytime soon (before 1.4.0). The @twinaphex 's comment here increased my hope and that's why I asked you to use the video_message_verbosity in your PR.

The original reason why I opened this issue is solved. I'm closing it but we can keep the conversation here (or in @Ryunam 's PR if you guys prefer).

[orbea]

Probably better to move the discussion to the PR.

[meleu]

@orbea it's already there. ;-)