hf-ikea
commented
5 months ago Cool 👍
Closed fizr5 closed 5 months ago
hf-ikea
commented
5 months ago Cool 👍
Simplydoge
commented
5 months ago Severe skill issue Mr. snowflake
ghost
commented
5 months ago What are you trying to accomplish here? you think insulting the developer and calling his software garbage will make him support your ancient hardware?
AlexandreRouma
commented
5 months ago Hello there!
Here some OpenGL 2.1 capable hardware your dumb, crap, bulshit software
If it's so crap, why are you trying to use it? I think you would feel more at home using SDRangel!
You do not test your crap software on your own.
You're right, all these years I've been writing it and never ran it for my own use, fascinating huh?
The developer of this software is making jokes of people having issues with his software and using a terrible wording in code, commits and bugreports.
Fuck yeah I do! And I'll fucking do it again!
The answer from the developer is completely wrong by fact. The implemented OpenGL version check is not doing some special hardware checks. It just look at the reported mesa OpenGL version. Every good and helpful developer would know that if a OpenGL mesa version check is in general fine, the software have to start. If the hardware report the required OpenGL version the software needs to run but for some reason the hardware cant run it, then the software have to start first and then crash. Instead its completely clear that the developer have not even a clue what his software is doing there when it should run with the fallback to OpenGL 2.1 - and this for years.
You seem very knowledgeable about software development, how about you write your own SDR software? It sounds like the community would love to see it! You seem extra knowledgeable about OpenGL extensions, and how even if a version is supported, not all features may be available and initializing the loader may fail! You know so much about this clearly!
BTW: This bug report is been immediately saved after post to https://web.archive.org/ . If you delete it, it would be a even more bad reputation for you because this would prove, that not you only make jokes at your users instead of helping them but also try to get rid of critics.
Thanks for archiving your stupidity for the rest of time!
If you're looking for a more serious answer: I don't value your opinion, I don't care about what you think about my software. I don't care what you think about the way I handle issues. If you're not happy about it, shut the fuck up, make your own software and contributed something to the SDR community like I've been doing for free for the past 4 years and maybe we can talk again. You're getting my years work for free and you still find a way to bitch about it. You're one of these people that has not been told "no" enough while growing up. You really need to understand that you are not entitled to other people's time and attention, and when behaving like that, you make sure of that fact that you'll be treated like the little whiny piece of shit you are.
Please, I beg you, never use my software again. Make sure to bitch about it online at every chance you get so people know immediately the kind of moron you are.
Best regards, Ryzerth
fizr5
commented
4 months ago @banantom
What are you trying to accomplish here? you think insulting the developer and calling his software garbage will make him support your ancient hardware?
If this was not that clear, i would like to explain it in short:
I am not a active user of such hardware. I have the knowledge, that those hardware support OpenGL 2.1 when i have seen the other closed bugreports from other poor people that could not help out on their own and believed the proven lie of @AlexandreRouma that their hardware does not support OpenGL 2.1 . Then i went to my storage room where i have a bunch of hardware i use to test different things and grab an old device that support OpenGL 2.1 but not OpenGL 3 (hardware1 and hardware2) and tried it out. I was able to confirm the issue. OpenGL 2.1 support is advertised by the sdrpp software but the support is broken like reported by many others. SDR++ currently only work with OpenGL 3 and OpenGL ES 3.
The main goal was to fix this issue for the affected people with this detailed bugreport. If you are a linux user, you and every other user can reproduce this error on modern hardware by simply running
env MESA_GL_VERSION_OVERRIDE="2.1" MESA_GLES_VERSION_OVERRIDE="2.0" sdrpp
The point you note about insulting the developer is just a side point. I am just using his style of naming things that he does not like but more important, he is using to insult people who are poor to buy more modern hardware. This is really extremely bad. No one should ever insult people just because they are poor or use older hardware. Calling his software like this is just his wording style. If the developer use this wording for other software he use, then he should be totally fine with this. His respond was interesting and sad on the other side. He seems to be fine with naming other software the way he name it, but if someone name his software the way he name other, then he gets really angry. This have sadly proven bad parts of the character of @AlexandreRouma
@AlexandreRouma
Here some OpenGL 2.1 capable hardware your dumb, crap, bulshit software If it's so crap, why are you trying to use it?
To help all the other people who want to use it on their hardware because they are poor or simply don't have other hardware. Stop telling those people the proven lie their Hardware wont support OpenGL 2.1 when it does.
You do not test your crap software on your own. You're right, all these years I've been writing it and never ran it for my own use, fascinating huh?
Then show the log output from env MESA_GL_VERSION_OVERRIDE="2.1" MESA_GLES_VERSION_OVERRIDE="2.0" sdrpp on your hardware. Or like written in the bug report because you request it - post a screenshot.
The developer of this software is making jokes of people having issues with his software and using a terrible wording in code, commits and bugreports. Fuck yeah I do! And I'll fucking do it again!
Why are you then pissed of when someone use the same terrible wording you use in bug reports? It should be just your everyday conversation style in your life. Then you should not even feel some difference. Its a normal conversation in your life.
The answer from the developer is completely wrong by fact. The implemented OpenGL version check is not doing some special hardware checks. It just look at the reported mesa OpenGL version. Every good and helpful developer would know that if a OpenGL mesa version check is in general fine, the software have to start. If the hardware report the required OpenGL version the software needs to run but for some reason the hardware cant run it, then the software have to start first and then crash. Instead its completely clear that the developer have not even a clue what his software is doing there when it should run with the fallback to OpenGL 2.1 - and this for years.
You seem very knowledgeable about software development, how about you write your own SDR software? It sounds like the community would love to see it!
I know how to use https://docs.mesa3d.org/envvars.html . If you name this being very knowledgeable about software development, that this is your opinion. Your conclusion out of this just do not make sense. Why should i write my own SDR software when the people are having issues with yours and reporting a bug in the hope of you fixing yours?
You seem extra knowledgeable about OpenGL extensions, and how even if a version is supported, not all features may be available and initializing the loader may fail! You know so much about this clearly!
How does the command line output of env MESA_GL_VERSION_OVERRIDE="2.1" MESA_GLES_VERSION_OVERRIDE="2.0" sdrpp look on your machine? Because you know so much yourself about OpenGL, you should know if your own hardware support OpenGL 2.1 and could run the software without a problem.
BTW: This bug report is been immediately saved after post to https://web.archive.org/ . If you delete it, it would be a even more bad reputation for you because this would prove, that not you only make jokes at your users instead of helping them but also try to get rid of critics.
Thanks for archiving your stupidity for the rest of time!
No, its your stupidity archived for the rest of your life. This new state of this bugreport is now again saved to https://web.archive.org/ EDIT: https://web.archive.org/web/20240210131531/https://github.com/AlexandreRouma/SDRPlusPlus/issues/1325
If you're looking for a more serious answer: I don't value your opinion, I don't care about what you think about my software. I don't care what you think about the way I handle issues. If you're not happy about it, shut the fuck up, make your own software and contributed something to the SDR community like I've been doing for free for the past 4 years and maybe we can talk again. You're getting my years work for free and you still find a way to bitch about it. You're one of these people that has not been told "no" enough while growing up. You really need to understand that you are not entitled to other people's time and attention, and when behaving like that, you make sure of that fact that you'll be treated like the little whiny piece of shit you are.
No, i was mainly looking for a answer in form of a changeset in this software that fixes the OpenGL 2.1 issue your software have and many people reported this issues in the last years.
BTW: This was not a serious answer from you on a bug report. It was the opposite. It had nothing to do with bug report. Apart for this its interesting to see the response. Especially 'You're one of these people that has not been told "no" enough while growing up.' . This is not something someone would in general come up with. In most cases it tells something about the person who starts with such a strange point. My expectation would be that when you grow up you got told "no" much more then you liked. Then this is sad that you did not have a free childhood you could have filled up with your character and dreams. But now use for the rest of your life such wording when other people are reporting bugs is also not a solution. You seem to not be happy if someone else is using this wording to you.
Please, I beg you, never use my software again.
I for sure would use it like i did for long time. Its working on my OpenGL 3 capable hardware i use and you have already fixed things i reported from an other username sometime before. But i was not using your wording there like you probably can think of.
I would now put the older hardware back in the storage to be able to test things on it if needed again like it was this time to debug and report this issue.
Lets see when the issue gets fixed for the people who needs the fix.
PS: https://github.com/AlexandreRouma/SDRPlusPlus/issues/new?assignees=&labels=bug&projects=&template=bug_report.md&title= is still telling this crap to all your users:
sdrpp -c
Before you close the issue only because of your dumb warning to fill up the form and do not read the full issue report i have done in hours of work:
Here some OpenGL 2.1 capable hardware your dumb, crap, bulshit software (wording you use often about other software (example1 example2 ) , lets see if you like it yourself) is NOT working:
Hardware1
Hardware2
Hardware3
Hardware4
Software
Bug Description You do not test your crap software on your own. You have written years ago a fallback mechanism from OpenGL 3 -> OpenGL ES 3 -> OpenGL 2.1. After hours of testing on my side and reading issue reports from other people you just ignore, its known that this part is not working and you have not even tested it for years: https://github.com/AlexandreRouma/SDRPlusPlus/blob/master/core/backends/glfw/backend.cpp#L178
Steps To Reproduce
Only If SDR++ fails to lauch or the SDR fails to start:
sdrpp -cYea, your crap form the people should fill out continues. But lets follow this crap at first. Here is the output you really want to see because you are telling everyone to run it like this: sdrpp -c [INFO] SDR++ v1.1.0 Unknown argument -a --addr Server mode address --autostart Automatically start the SDR after loading -h --help Show help -p --port Server mode port -r --root Root directory, where all config files are stored -s --server Run in server modeScreenshots You can make some screenshots by yourself from your screen after running: env MESA_GL_VERSION_OVERRIDE="2.1" MESA_GLES_VERSION_OVERRIDE="2.0" sdrpp
Additional info The developer of this software is making jokes of people having issues with his software and using a terrible wording in code, commits and bugreports. This developer here is not Linus Torwalds who really brings things exactly on point like the really famous https://www.wired.com/2012/06/torvalds-nvidia-linux/ . Instead this developer is making jokes of people who do not have money like in https://github.com/AlexandreRouma/SDRPlusPlus/issues/1306 instead of fixing his crap software and giving some tips what people could try out (take a look at the link behind OpenGL version 2.1 on linux) https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units#Third_generation This useless bugreport closing is going on for years instead of fixing his crap software that cause the issue for example in this bug report: https://github.com/AlexandreRouma/SDRPlusPlus/issues/820
And what really makes me angry is this: https://github.com/AlexandreRouma/SDRPlusPlus/discussions/823 There you can see that an old person is searching for help. The old person have provided all the required information. Nice and helpful people would have seen on the Screenshot the old person have send in the naming of the computer "K52F". A 5 second search show: https://devicelist.best/en/asus-k52f/ . CPU+GPU is Intel first core i-gen and thus supporting OpenGL 2.1. Instead of helping the old person he is been let alone.
I had seen this and many other bug reports by the people and have done some research and knew the issue is in the software because it tells it would use OpenGL 2.1 but it never does on any hardware. Afterwards i thought "come on, lets see if when i point the developer to exactly the problem and the developer wont have to know anything about the hardware if the developer would still fully ignore the issue." I wrote this bugreport: https://github.com/AlexandreRouma/SDRPlusPlus/issues/1322 And yes, even then the developer fully ignores a bug report based only on the pure issue that cant be overseen. The answer from the developer is completely wrong by fact. The implemented OpenGL version check is not doing some special hardware checks. It just look at the reported mesa OpenGL version. Every good and helpful developer would know that if a OpenGL mesa version check is in general fine, the software have to start. If the hardware report the required OpenGL version the software needs to run but for some reason the hardware cant run it, then the software have to start first and then crash. Instead its completely clear that the developer have not even a clue what his software is doing there when it should run with the fallback to OpenGL 2.1 - and this for years.
Here is the perfect logfile to prove the issue for example ran on hardware3 with no possible excuse the hardware could maybe have not implemented OpenGL 2.1 in full: env MESA_GL_VERSION_OVERRIDE="2.1" glxinfo -B name of display: :0 display: :0 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel (0x8086) Device: Mesa Intel(R) HD Graphics 4000 (IVB GT2) (0x166) Version: 23.0.4 Accelerated: yes Video memory: 1536MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 2.1 Max compat profile version: 2.1 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.0 OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) HD Graphics 4000 (IVB GT2) OpenGL version string: 2.1 Mesa 23.0.4-0ubuntu1~22.04.1 OpenGL shading language version string: 1.20
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 23.0.4-0ubuntu1~22.04.1 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
env MESA_GL_VERSION_OVERRIDE="2.1" /usr/bin/sdrpp [INFO] SDR++ v1.1.0 [INFO] Loading config [ERROR] Glfw Error 65543: GLX: Failed to create context: GLXBadFBConfig [INFO] OpenGL 3.0 was not supported [ERROR] Glfw Error 65543: GLX: Failed to create context: GLXBadFBConfig [INFO] OpenGL 3.1 ES was not supported [INFO] Using OpenGL 2.1 Failed to initialize OpenGL loader! [WARN] Could not init using OpenGL with normal GLSL version, falling back to GLSL 1.2 Failed to initialize OpenGL loader! [ERROR] Failed to initialize OpenGL with GLSL 1.2
BTW: This bug report is been immediately saved after post to https://web.archive.org/ . If you delete it, it would be a even more bad reputation for you because this would prove, that not you only make jokes at your users instead of helping them but also try to get rid of critics. EDIT: https://web.archive.org/web/20240208050535/https://github.com/AlexandreRouma/SDRPlusPlus/issues/1325