-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kernel update without module update F28 #82
Comments
This is a duplicate of #78 . Also, see this: DisplayLink/evdi#145 |
The proposed fixes that are being posted are not the proper way to solve
this. I am down voting to discourage following the use of these misleading
instructions. You should not re-define the kernel flag that was used in
kernels prior to 4.20. The proper fix is to check which kernel you are
compiling against and then set `info->flags` accordingly for backwards
compatibility. For kernel 4.20+, that flag has been removed from the
kernel and should not be used when setting `info->flags`.
…On Tue, Feb 12, 2019 at 6:03 PM Gerard Braad ***@***.***> wrote:
@elguero <https://github.com/elguero> why are you voting people down when
they propose to the add the missing flag with a #define ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABoJ7vu73FlvGvSzv8E-3GzIecvFyeuDks5vM0hKgaJpZM4a2DcW>
.
|
Why don’t you post instructions or a link then and educate people. Most people don’t even know wtf you just said. They are just trying to use their computer. |
@sorvani Wow... sorry for trying to be helpful and answer someone's question. I did post a link in my prior comment. The proper fix is in #78. Please see the specific comment here on the proper fix since you obviously didn't find it: #78 (comment) It is the regular computer user that follows instructions posted on the Internet blindly that I was trying to help out by down voting the improper instructions of re-defining the kernel flag to equal 1. |
The comment of sorvani makes some sense, because my concern about downvoting is that there was no comment, and this is bad practice. But yes, without proper logic to handle kernel verrsions for the define is general bad practice but it helped people forward. The issue is that most people have now been waiting for almost a month to a month or more to get a working situation. Please see: DisplayLink/evdi#148 (comment) |
Thank you all for the comments. But to a user with minimal coding capabilities and next to zero time to self patch (like myself), the only valuable comment is this: DisplayLink/evdi#148 (comment) So basically to my understanding, we just have to wait for the new code, towards a new rpm? Thnx |
Yep - understood. I just didn't want to repeat what someone else had already pointed out. It just clutters up the comments. I will keep that in mind next time to be mindful of adding comments when necessary. I too have been patiently waiting. I am still using kernel 2.19 when I know I need to hookup my laptop to multiple monitors. @tkontogi Correct. It looks like the fix will be released soon. |
This looks to me like a solution has been committed. |
Right, but be aware... this update is NOT backwards compatible with kernels < v4.2 (DisplayLink/evdi#145 (comment)) |
@gbraad That shouldn't be a problem since he is on Fedora 28. Correct? The original issue was with kernels > 4.19. Anyone on kernels 4.2 or below will need to stick with the v1.5 of displaylink. @tkontogi The code has been committed. They just need to release v1.6. Then we need to wait for the RPM to be updated with the latest evdi driver release which should bump the displaylink rpm version up to 1.6, if my understanding is correct. |
First, this is a duplicate of #78, so I'm closing this thread to keep a single thread on the same issue. However, a couple of points that don't need to be "ported over" there: @sorvani please keep in mind that we are here with the spirit of collaboration and building something for the commons. If you feel something is missing, approaching the issue constructively instead of sarcastically will definitely make things more enjoyable for everybody. @elguero you don't need to "wait for the RPM to be updated", it does not happen on its own. Someone will have to do it! If you want to contribute to have this out ASAP, you can see several previous patches in the merged PRs, but as an example, https://github.com/displaylink-rpm/displaylink-rpm/pull/58/files Also, guys, I don't know what you are referring you want to down-vote about, couldn't make sense of that part (any clarification?) Keep in mind that this repository is currently maintained by community members who are not affiliated with DisplayLink Inc., and we do this on our own time. If you need this for your work, you can consider contributing a PR yourself. |
@ssaavedra Thanks for chiming in and constructive comments. What you clarified is what I meant. Sorry to imply it happened automatically. To answer your question, I received an email asking why I was "voting people down". I took that to mean, why am I "thumbs downing" comments where people were suggesting to re-define the flag. I responded to the email by replying through email, which attached my email response to this issue. You have to expand it to see the original email I received. Thanks for the continued support of maintaining RPMs for the community to use. |
Hello and thank you for the Great Job.
I have the following issue.
On F28 every kernel update breaks display rpm installation with "modprobe: FATAL: Module evdi not found in directory /lib/modules/4.20.6-100.fc28.x86_64"
I do the following:
And then
make.log can be found here: https://paste.fedoraproject.org/paste/cPYosH2mr7OD4kgWLvakMA
Visited issue #60 to get more ides, but no good and this is as much as I can go into regarding compilation, without step by step guidance.
Also there are some evdi related issues around but as I said my compilation related knowledge is not good enough this point on.
Thank you.
The text was updated successfully, but these errors were encountered: