Finding commit history of a specific kernel module: i915

[Gus Wirth]

I have an older Dell laptop, a Latitude E6410 with an Intel i7-640M
processor, previously known as Arrandale, which first came out in 2010.
It has integrated Intel graphics driven by the i915 kernel module.

Somewhere between the 4.13.13 and 4.14.x kernel, something changed to
cause the background to have an annoying 60Hz (or maybe 30Hz ?) flicker
when running X-windows. It looks like a florescent bulb that is starting
to go bad. I know the problem is in the kernel because the only thing I
change is the kernel at boot time, everything else stays the same. I've
tried different desktop environments (KDE and LXDE), different options
for the i915 kernel module but nothing seems to work. I'm running Fedora
27 64-bit on the laptop. Ubuntu 17.10 had the 4.13 kernel and does not
show the problem. I haven't found a live distro with the 4.14 kernel yet
to test if the problem might be something done by Red Hat.

So now I want to try and see if I can find the commit that caused the
problem. My first step would be to see if I can review the commits to
the i915 kernel module to find if anything seems obvious. If not, I
would really rather only have to rebuild the i915 kernel module to do
the bisect rather than rebuild the whole kernel every time. I'm working
from the assumption that the same module will still work over different
versions of the kernel, but that might not be a good assumption.

Is there any way to get a commit history for only a single module? I'm
not familiar enough with git to know if that can be done and there
doesn't seem to be a web interface to let me see what's been going on.
Otherwise I'll just have to build a few kernels to find out what happened.

Gus

[Rich Ernst]

Looks like slackware based slackex has the newer kernel.

http://news.softpedia.com/news/slackware-based-slackex-distro-released-with-linux-kernel-4-14-8-and-kde-4-14-38-519114.shtml

SlackEX website

http://www.slackex.exton.net/

I didn't read fully, but it looked like they have a live version.

Rich

Post by Gus Wirth
I have an older Dell laptop, a Latitude E6410 with an Intel i7-640M
processor, previously known as Arrandale, which first came out in 2010. It
has integrated Intel graphics driven by the i915 kernel module.
Somewhere between the 4.13.13 and 4.14.x kernel, something changed to cause
the background to have an annoying 60Hz (or maybe 30Hz ?) flicker when
running X-windows. It looks like a florescent bulb that is starting to go
bad. I know the problem is in the kernel because the only thing I change is
the kernel at boot time, everything else stays the same. I've tried
different desktop environments (KDE and LXDE), different options for the
i915 kernel module but nothing seems to work. I'm running Fedora 27 64-bit
on the laptop. Ubuntu 17.10 had the 4.13 kernel and does not show the
problem. I haven't found a live distro with the 4.14 kernel yet to test if
the problem might be something done by Red Hat.
So now I want to try and see if I can find the commit that caused the
problem. My first step would be to see if I can review the commits to the
i915 kernel module to find if anything seems obvious. If not, I would really
rather only have to rebuild the i915 kernel module to do the bisect rather
than rebuild the whole kernel every time. I'm working from the assumption
that the same module will still work over different versions of the kernel,
but that might not be a good assumption.
Is there any way to get a commit history for only a single module? I'm not
familiar enough with git to know if that can be done and there doesn't seem
to be a web interface to let me see what's been going on. Otherwise I'll
just have to build a few kernels to find out what happened.
Gus
--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

[Brad Beyenhof]

Is there any way to get a commit history for only a single module? I'm not familiar enough with git to know if that can be done and there doesn't seem to be a web interface to let me see what's been going on. Otherwise I'll just have to build a few kernels to find out what happened.

If you clone the Linux source and can find the specific directory or file, you can 'git log $PATH' to get the history of commits that refer to just the specified files.

[David Brown]

Post by Brad Beyenhof

Post by Gus Wirth
Is there any way to get a commit history for only a single module?
I'm not familiar enough with git to know if that can be done and
there doesn't seem to be a web interface to let me see what's been
going on. Otherwise I'll just have to build a few kernels to find
out what happened.

If you clone the Linux source and can find the specific directory or
file, you can 'git log $PATH' to get the history of commits that
refer to just the specified files.

One caveat to this is that sometimes things are moved around in the
kernel. `git log` has a `--follow` argument tha tries to follow this.
I tried this on the 915 driver and it didn't seem to follow much, so,
you can do something like this:

$ git log drivers/gpu/drm/i915
...
commit c0e09200dc0813972442e550a5905a132768e56c
Author: Dave Airlie <***@redhat.com>
Date: Thu May 29 10:09:59 2008 +1000

drm: reorganise drm tree to be more future proof.

and this is the last this command shows, with the drm tree being
reorganized. We can look at this commit in more detail:

$ git show --stat c0e09200dc
...
drivers/{char/drm => gpu/drm/i915}/i915_dma.c | 0

So, it looks like this patch made it easier by putting all of the i915
drivers in their own directory.

Fortunately, git is pretty smart about this:

$ git log drivers/char/drm/i915'*'
...
commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (tag: v2.6.12-rc2)
Author: Linus Torvalds <***@ppc970.osdl.org>
Date: Sat Apr 16 15:20:36 2005 -0700

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,

At this point, we have the first commit that was entered into git. If
you need history beyond this, there are people who have build other
git repos holding earlier history (reconstructed from releases). But,
2005 is usually early enough to find most things.

Hope this help,
David

[Gus Wirth]

Post by David Brown

Post by Brad Beyenhof

Post by Gus Wirth
Is there any way to get a commit history for only a single module?
I'm not familiar enough with git to know if that can be done and
there doesn't seem to be a web interface to let me see what's been
going on. Otherwise I'll just have to build a few kernels to find
out what happened.

If you clone the Linux source and can find the specific directory or
file, you can 'git log $PATH' to get the history of commits that
refer to just the specified files.

One caveat to this is that sometimes things are moved around in the
kernel. `git log` has a `--follow` argument tha tries to follow this.
I tried this on the 915 driver and it didn't seem to follow much, so,
$ git log drivers/gpu/drm/i915
...
commit c0e09200dc0813972442e550a5905a132768e56c
Date: Thu May 29 10:09:59 2008 +1000
drm: reorganise drm tree to be more future proof.
and this is the last this command shows, with the drm tree being
$ git show --stat c0e09200dc
...
drivers/{char/drm => gpu/drm/i915}/i915_dma.c | 0
So, it looks like this patch made it easier by putting all of the i915
drivers in their own directory.
$ git log drivers/char/drm/i915'*'
...
commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (tag: v2.6.12-rc2)
Date: Sat Apr 16 15:20:36 2005 -0700
Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
At this point, we have the first commit that was entered into git. If
you need history beyond this, there are people who have build other
git repos holding earlier history (reconstructed from releases). But,
2005 is usually early enough to find most things.

Thanks for the tips. I tried looking at the commits to the i915 module
but it was overwhelming so I wound up doing a bisect on the kernel.
After building the kernel 16 times I found the culprit:

commit dc911f5bd8aacfcf8aabd5c26c88e04c837a938e
Author: Jim Bride <***@linux.intel.com>
Date: Wed Aug 9 12:48:53 2017 -0700

drm/i915/edp: Allow alternate fixed mode for eDP if available.
...

Searching for this commit on the Internet reveals that this has been a
known problem since August 2017 when the commit was initially made, but
there doesn't seem to be much interest in fixing it.

The work around is to to create a custom mode entry in
/etc/X11/xorg.conf.d/ that describes the laptop display panel (monitor)
and binds it to the driver.

It's been awhile since I've had to create xorg.conf entries so I was
surprised that instead of having a specific driver for the GPU (intel)
it uses a generic "modesetting" driver that talks to the kernel
modesetting module, i915 in this case. I may have to dig out my old X
Windows lecture, give it an update and do a presentation.

Gus

[Tony Su]

Before you go about messing with an xorg.conf,
You might consider a Wayland implementation.
At least in openSUSE, the various Desktops are pushing as hard as they
can to replace sorg with Wayland.
But don't hold your breath too much about Wayland....
We've only had a pretty solid KDE Wayland implementation now for about
6 months, and that was after early steps in our Enlightenment Desktop
about 2 years ago.
And, no matter the Desktop, Wayland still lacks features... perhaps
most noticeably, does not support remote X sessions, so in those cases
an xorg x-server has to be running (typically side by side with
Wayland).

Despite the slow progress, IMO Wayland will eventually replace xorg,
so particularly if for instance your preferred distro is Fedora,
you'll probably see Wayland sooner than not, and when that happens
your xorg.conf work will be obsolete.

Yeah, I know how hard it can be to decide how much to invest in a soon
to be deprecated technology before its replacement might be ready, but
that's life sometimes.

Tony

Post by David Brown

Post by Brad Beyenhof

Post by Gus Wirth
Is there any way to get a commit history for only a single module?
I'm not familiar enough with git to know if that can be done and
there doesn't seem to be a web interface to let me see what's been
going on. Otherwise I'll just have to build a few kernels to find
out what happened.

If you clone the Linux source and can find the specific directory or
file, you can 'git log $PATH' to get the history of commits that
refer to just the specified files.

One caveat to this is that sometimes things are moved around in the
kernel. `git log` has a `--follow` argument tha tries to follow this.
I tried this on the 915 driver and it didn't seem to follow much, so,
$ git log drivers/gpu/drm/i915
...
commit c0e09200dc0813972442e550a5905a132768e56c
Date: Thu May 29 10:09:59 2008 +1000
drm: reorganise drm tree to be more future proof.
and this is the last this command shows, with the drm tree being
$ git show --stat c0e09200dc
...
drivers/{char/drm => gpu/drm/i915}/i915_dma.c | 0
So, it looks like this patch made it easier by putting all of the i915
drivers in their own directory.
$ git log drivers/char/drm/i915'*'
...
commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (tag: v2.6.12-rc2)
Date: Sat Apr 16 15:20:36 2005 -0700
Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
At this point, we have the first commit that was entered into git. If
you need history beyond this, there are people who have build other
git repos holding earlier history (reconstructed from releases). But,
2005 is usually early enough to find most things.

Thanks for the tips. I tried looking at the commits to the i915 module but
it was overwhelming so I wound up doing a bisect on the kernel. After
commit dc911f5bd8aacfcf8aabd5c26c88e04c837a938e
Date: Wed Aug 9 12:48:53 2017 -0700
drm/i915/edp: Allow alternate fixed mode for eDP if available.
...
Searching for this commit on the Internet reveals that this has been a known
problem since August 2017 when the commit was initially made, but there
doesn't seem to be much interest in fixing it.
The work around is to to create a custom mode entry in /etc/X11/xorg.conf.d/
that describes the laptop display panel (monitor) and binds it to the
driver.
It's been awhile since I've had to create xorg.conf entries so I was
surprised that instead of having a specific driver for the GPU (intel) it
uses a generic "modesetting" driver that talks to the kernel modesetting
module, i915 in this case. I may have to dig out my old X Windows lecture,
give it an update and do a presentation.
Gus
--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

[Gus Wirth]

Post by Tony Su
Before you go about messing with an xorg.conf,
You might consider a Wayland implementation.
At least in openSUSE, the various Desktops are pushing as hard as they
can to replace sorg with Wayland.
But don't hold your breath too much about Wayland....
We've only had a pretty solid KDE Wayland implementation now for about
6 months, and that was after early steps in our Enlightenment Desktop
about 2 years ago.
And, no matter the Desktop, Wayland still lacks features... perhaps
most noticeably, does not support remote X sessions, so in those cases
an xorg x-server has to be running (typically side by side with
Wayland).
Despite the slow progress, IMO Wayland will eventually replace xorg,
so particularly if for instance your preferred distro is Fedora,
you'll probably see Wayland sooner than not, and when that happens
your xorg.conf work will be obsolete.
Yeah, I know how hard it can be to decide how much to invest in a soon
to be deprecated technology before its replacement might be ready, but
that's life sometimes.

You are confusing the display server, Wayland and Xorg, which are user
space applications, with the the video card driver, which is a kernel
module. Both Xorg and Wayland talk to the i915 (intel GPU) kernel module
to have the video card draw stuff for them.

The problem in this case is in the Linux kernel itself, specifically the
i915 kernel module. This is independent of the display server. What is
happening is that the i915 module is incorrectly responding to mode
setting commands, which will affect any program trying to use the i915
module.

For an overview of Wayland see https://wayland.freedesktop.org/

Gus

[Kevin Keane Subscription]

Aside from Gus’ comments, IIRC, Wayland isn’t intended to replace, but complement xorg. Wayland is for local display rendering, while xorg will remain relevant for remote sessions.

 
There also is a question about inertia. For better or for worse, we’ve seen an increasing resistance and inertia against replacing familiar fundamental technologies. Not just on Linux, but throughout IT. There still is a lot of pushback against systemd, six years after the international IPv6 day, it is on life support outside the mobile space and a few niches, Unity has actually died, even Microsoft had to backpedal on the tiled UI, and so on.

 
With that in mind, I give Wayland only a 50% chance of catching on.

 
Sent from Mail for Windows 10

 
From: Tony Su <mailto:***@su-networking.com>
Sent: Wednesday, February 28, 2018 8:26 AM
To: Main Discussion List for KPLUG <mailto:kplug-***@kernel-panic.org>
Subject: Re: Finding commit history of a specific kernel module: i915

 


Before you go about messing with an xorg.conf,
You might consider a Wayland implementation.
At least in openSUSE, the various Desktops are pushing as hard as they
can to replace sorg with Wayland.
But don't hold your breath too much about Wayland....
We've only had a pretty solid KDE Wayland implementation now for about
6 months, and that was after early steps in our Enlightenment Desktop
about 2 years ago.
And, no matter the Desktop, Wayland still lacks features... perhaps
most noticeably, does not support remote X sessions, so in those cases
an xorg x-server has to be running (typically side by side with
Wayland).

Despite the slow progress, IMO Wayland will eventually replace xorg,
so particularly if for instance your preferred distro is Fedora,
you'll probably see Wayland sooner than not, and when that happens
your xorg.conf work will be obsolete.

Yeah, I know how hard it can be to decide how much to invest in a soon
to be deprecated technology before its replacement might be ready, but
that's life sometimes.

Tony

Post by David Brown

Post by Brad Beyenhof

Post by Gus Wirth
Is there any way to get a commit history for only a single module?
I'm not familiar enough with git to know if that can be done and
there doesn't seem to be a web interface to let me see what's been
going on. Otherwise I'll just have to build a few kernels to find
out what happened.

If you clone the Linux source and can find the specific directory or
file, you can 'git log $PATH' to get the history of commits that
refer to just the specified files.

One caveat to this is that sometimes things are moved around in the
kernel.  `git log` has a `--follow` argument tha tries to follow this.
I tried this on the 915 driver and it didn't seem to follow much, so,
      $ git log drivers/gpu/drm/i915
      ...
      commit c0e09200dc0813972442e550a5905a132768e56c
      Date:   Thu May 29 10:09:59 2008 +1000
          drm: reorganise drm tree to be more future proof.
and this is the last this command shows, with the drm tree being
      $ git show --stat c0e09200dc
      ...
       drivers/{char/drm => gpu/drm/i915}/i915_dma.c           |  0
So, it looks like this patch made it easier by putting all of the i915
drivers in their own directory.
      $ git log drivers/char/drm/i915'*'
      ...
      commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (tag: v2.6.12-rc2)
      Date:   Sat Apr 16 15:20:36 2005 -0700
          Linux-2.6.12-rc2
               Initial git repository build. I'm not bothering with the
full history,
At this point, we have the first commit that was entered into git.  If
you need history beyond this, there are people who have build other
git repos holding earlier history (reconstructed from releases).  But,
2005 is usually early enough to find most things.

Thanks for the tips. I tried looking at the commits to the i915 module but
it was overwhelming so I wound up doing a bisect on the kernel. After
commit dc911f5bd8aacfcf8aabd5c26c88e04c837a938e
Date:   Wed Aug 9 12:48:53 2017 -0700
     drm/i915/edp: Allow alternate fixed mode for eDP if available.
...
Searching for this commit on the Internet reveals that this has been a known
problem since August 2017 when the commit was initially made, but there
doesn't seem to be much interest in fixing it.
The work around is to to create a custom mode entry in /etc/X11/xorg.conf.d/
that describes the laptop display panel (monitor) and binds it to the
driver.
It's been awhile since I've had to create xorg.conf entries so I was
surprised that instead of having a specific driver for the GPU (intel) it
uses a generic "modesetting" driver that talks to the kernel modesetting
module, i915 in this case. I may have to dig out my old X Windows lecture,
give it an update and do a presentation.
Gus
--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

--
KPLUG-***@kernel-panic.org
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

[Dante Lanznaster]

Huh? Both Wayland and X11 (xorg) are display servers. They have their
differences, but AFAIK Wayland came to replace X11, even though it's not
there yet.

On Wed, Feb 28, 2018 at 9:20 PM, Kevin Keane Subscription <

Post by Kevin Keane Subscription
Aside from Gus’ comments, IIRC, Wayland isn’t intended to replace, but
complement xorg. Wayland is for local display rendering, while xorg will
remain relevant for remote sessions.
There also is a question about inertia. For better or for worse, we’ve
seen an increasing resistance and inertia against replacing familiar
fundamental technologies. Not just on Linux, but throughout IT. There still
is a lot of pushback against systemd, six years after the international
IPv6 day, it is on life support outside the mobile space and a few niches,
Unity has actually died, even Microsoft had to backpedal on the tiled UI,
and so on.
With that in mind, I give Wayland only a 50% chance of catching on.
Sent from Mail for Windows 10
Sent: Wednesday, February 28, 2018 8:26 AM
Subject: Re: Finding commit history of a specific kernel module: i915
Before you go about messing with an xorg.conf,
You might consider a Wayland implementation.
At least in openSUSE, the various Desktops are pushing as hard as they
can to replace sorg with Wayland.
But don't hold your breath too much about Wayland....
We've only had a pretty solid KDE Wayland implementation now for about
6 months, and that was after early steps in our Enlightenment Desktop
about 2 years ago.
And, no matter the Desktop, Wayland still lacks features... perhaps
most noticeably, does not support remote X sessions, so in those cases
an xorg x-server has to be running (typically side by side with
Wayland).
Despite the slow progress, IMO Wayland will eventually replace xorg,
so particularly if for instance your preferred distro is Fedora,
you'll probably see Wayland sooner than not, and when that happens
your xorg.conf work will be obsolete.
Yeah, I know how hard it can be to decide how much to invest in a soon
to be deprecated technology before its replacement might be ready, but
that's life sometimes.
Tony

Post by Gus Wirth

Post by David Brown

Post by Brad Beyenhof

Post by Gus Wirth
Is there any way to get a commit history for only a single module?
I'm not familiar enough with git to know if that can be done and
there doesn't seem to be a web interface to let me see what's been
going on. Otherwise I'll just have to build a few kernels to find
out what happened.

If you clone the Linux source and can find the specific directory or
file, you can 'git log $PATH' to get the history of commits that
refer to just the specified files.

One caveat to this is that sometimes things are moved around in the
kernel. `git log` has a `--follow` argument tha tries to follow this.
I tried this on the 915 driver and it didn't seem to follow much, so,
$ git log drivers/gpu/drm/i915
...
commit c0e09200dc0813972442e550a5905a132768e56c
Date: Thu May 29 10:09:59 2008 +1000
drm: reorganise drm tree to be more future proof.
and this is the last this command shows, with the drm tree being
$ git show --stat c0e09200dc
...
drivers/{char/drm => gpu/drm/i915}/i915_dma.c | 0
So, it looks like this patch made it easier by putting all of the i915
drivers in their own directory.
$ git log drivers/char/drm/i915'*'
...
commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (tag: v2.6.12-rc2)
Date: Sat Apr 16 15:20:36 2005 -0700
Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the
full history,
At this point, we have the first commit that was entered into git. If
you need history beyond this, there are people who have build other
git repos holding earlier history (reconstructed from releases). But,
2005 is usually early enough to find most things.

Thanks for the tips. I tried looking at the commits to the i915 module

but

Post by Gus Wirth
it was overwhelming so I wound up doing a bisect on the kernel. After
commit dc911f5bd8aacfcf8aabd5c26c88e04c837a938e
Date: Wed Aug 9 12:48:53 2017 -0700
drm/i915/edp: Allow alternate fixed mode for eDP if available.
...
Searching for this commit on the Internet reveals that this has been a

known

Post by Gus Wirth
problem since August 2017 when the commit was initially made, but there
doesn't seem to be much interest in fixing it.
The work around is to to create a custom mode entry in

/etc/X11/xorg.conf.d/

Post by Gus Wirth
that describes the laptop display panel (monitor) and binds it to the
driver.
It's been awhile since I've had to create xorg.conf entries so I was
surprised that instead of having a specific driver for the GPU (intel) it
uses a generic "modesetting" driver that talks to the kernel modesetting
module, i915 in this case. I may have to dig out my old X Windows

lecture,

Post by Gus Wirth
give it an update and do a presentation.
Gus
--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

[Tony Su]

Gus,
Are you saying that you're configuring the <display driver> using xorg.conf?
If you're doing so, that's something new to me.

For many years now in openSUSE, all situations I know of regarding the
display driver are configured elsewhere,
And the general rule for many years (and many openSUSE versions) has
been to <don't> create or use an xorg.conf by default (for both xorg
and wayland x-servers). If you <do> create an xorg-conf file, then
it's understood that the file will over-ride settings set by default
by the kernel and elsewhere <and> activate an xorg x-server.

Although I don't use Fedora regularly, because of the close
relationship between these two distros I generally assume that basic
principles in one can be expected to also be the same in the other.

Tony

Post by Dante Lanznaster
Huh? Both Wayland and X11 (xorg) are display servers. They have their
differences, but AFAIK Wayland came to replace X11, even though it's not
there yet.
On Wed, Feb 28, 2018 at 9:20 PM, Kevin Keane Subscription <

Post by Kevin Keane Subscription
Aside from Gus’ comments, IIRC, Wayland isn’t intended to replace, but
complement xorg. Wayland is for local display rendering, while xorg will
remain relevant for remote sessions.
There also is a question about inertia. For better or for worse, we’ve
seen an increasing resistance and inertia against replacing familiar
fundamental technologies. Not just on Linux, but throughout IT. There still
is a lot of pushback against systemd, six years after the international
IPv6 day, it is on life support outside the mobile space and a few niches,
Unity has actually died, even Microsoft had to backpedal on the tiled UI,
and so on.
With that in mind, I give Wayland only a 50% chance of catching on.
Sent from Mail for Windows 10
Sent: Wednesday, February 28, 2018 8:26 AM
Subject: Re: Finding commit history of a specific kernel module: i915
Before you go about messing with an xorg.conf,
You might consider a Wayland implementation.
At least in openSUSE, the various Desktops are pushing as hard as they
can to replace sorg with Wayland.
But don't hold your breath too much about Wayland....
We've only had a pretty solid KDE Wayland implementation now for about
6 months, and that was after early steps in our Enlightenment Desktop
about 2 years ago.
And, no matter the Desktop, Wayland still lacks features... perhaps
most noticeably, does not support remote X sessions, so in those cases
an xorg x-server has to be running (typically side by side with
Wayland).
Despite the slow progress, IMO Wayland will eventually replace xorg,
so particularly if for instance your preferred distro is Fedora,
you'll probably see Wayland sooner than not, and when that happens
your xorg.conf work will be obsolete.
Yeah, I know how hard it can be to decide how much to invest in a soon
to be deprecated technology before its replacement might be ready, but
that's life sometimes.
Tony

Post by Gus Wirth

Post by David Brown

Post by Brad Beyenhof

Post by Gus Wirth
Is there any way to get a commit history for only a single module?
I'm not familiar enough with git to know if that can be done and
there doesn't seem to be a web interface to let me see what's been
going on. Otherwise I'll just have to build a few kernels to find
out what happened.

If you clone the Linux source and can find the specific directory or
file, you can 'git log $PATH' to get the history of commits that
refer to just the specified files.

One caveat to this is that sometimes things are moved around in the
kernel. `git log` has a `--follow` argument tha tries to follow this.
I tried this on the 915 driver and it didn't seem to follow much, so,
$ git log drivers/gpu/drm/i915
...
commit c0e09200dc0813972442e550a5905a132768e56c
Date: Thu May 29 10:09:59 2008 +1000
drm: reorganise drm tree to be more future proof.
and this is the last this command shows, with the drm tree being
$ git show --stat c0e09200dc
...
drivers/{char/drm => gpu/drm/i915}/i915_dma.c | 0
So, it looks like this patch made it easier by putting all of the i915
drivers in their own directory.
$ git log drivers/char/drm/i915'*'
...
commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (tag: v2.6.12-rc2)
Date: Sat Apr 16 15:20:36 2005 -0700
Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the
full history,
At this point, we have the first commit that was entered into git. If
you need history beyond this, there are people who have build other
git repos holding earlier history (reconstructed from releases). But,
2005 is usually early enough to find most things.

Thanks for the tips. I tried looking at the commits to the i915 module

but

Post by Gus Wirth
it was overwhelming so I wound up doing a bisect on the kernel. After
commit dc911f5bd8aacfcf8aabd5c26c88e04c837a938e
Date: Wed Aug 9 12:48:53 2017 -0700
drm/i915/edp: Allow alternate fixed mode for eDP if available.
...
Searching for this commit on the Internet reveals that this has been a

known

Post by Gus Wirth
problem since August 2017 when the commit was initially made, but there
doesn't seem to be much interest in fixing it.
The work around is to to create a custom mode entry in

/etc/X11/xorg.conf.d/

Post by Gus Wirth
that describes the laptop display panel (monitor) and binds it to the
driver.
It's been awhile since I've had to create xorg.conf entries so I was
surprised that instead of having a specific driver for the GPU (intel) it
uses a generic "modesetting" driver that talks to the kernel modesetting
module, i915 in this case. I may have to dig out my old X Windows

lecture,

Post by Gus Wirth
give it an update and do a presentation.
Gus
--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

[Gus Wirth]

Post by Tony Su
Gus,
Are you saying that you're configuring the <display driver> using xorg.conf?
If you're doing so, that's something new to me.

That's exactly what I'm saying. And it's been that way ever since the
first X Windows system.

Post by Tony Su
For many years now in openSUSE, all situations I know of regarding the
display driver are configured elsewhere,
And the general rule for many years (and many openSUSE versions) has
been to <don't> create or use an xorg.conf by default (for both xorg
and wayland x-servers). If you <do> create an xorg-conf file, then
it's understood that the file will over-ride settings set by default
by the kernel and elsewhere <and> activate an xorg x-server.
Although I don't use Fedora regularly, because of the close
relationship between these two distros I generally assume that basic
principles in one can be expected to also be the same in the other.

Probably the reason you don't realize what happens behind the scenes is
that both the Xorg teams and the kernel developers have worked very hard
to make things "just work" without any user intervention. This also goes
along with the hardware manufacturers incorporating built-in capability
detection.

Take for example a typical computer setup with a VGA monitor (although
DVI and HDMI have similar functions)and an Intel GPU (integrated into
the chipset or CPU), although NVidia and ATI (AMD) and others (Matrox,
etc) work similarly. The software running the system is a Linux kernel
and X-Windows. When the GPU (video card) is initialized it queries the
monitor connection(s) to see if something is attached. If there is, the
GPU then queries the display for its operating parameters and the
monitor reports using either DDC (Display Data Channel) or EDID
(Extended Display Identification Data). Things like the monitor size,
Horizontal x Vertical resolutions, dot clock, timings, etc. are reported
to the GPU. The video driver for a GPU is driven by the kernel. In the
case of Intel it's the i915 driver. The i915 driver exposes an interface
that can be accessed by user space programs, in this case X-Windows.

The X-Windows system talks to the i915 driver and receives the
information about the monitor and (usually) chooses the highest
resolution and refresh rate by default and tells the i915 module to set
those parameters in the GPU. That's because it's built in to the Xorg
server. Behind the scenes, the Xorg server is probing for input devices
(keyboard, mouse, etc), GPU, and monitor (via the GPU). Xorg then builds
an xorg.conf file on the fly internally to assemble all the pieces to
create your experience. You can find the result of all that probing and
assembly in the log file: /var/log/Xorg.0.log

The location and name of the log file might vary with the system. For
example, you can have multiple Xorg sessions running at the same time,
so the second session would have a log file named Xorg.1.log, etc.

The whole point of this is that you can either let the system do
everything for you automatically, which is what most people do, or you
can override the defaults and have it your way. You just need to read up
on how to make that happen. Start with "man Xorg" to get started.

The reason I know any of this is because I started my ventures in
X-Windows back when I had a 486 computer with a no name VGA card and a
640x480 monitor that was very finicky about timings. There was no DDC
then. The specifics of how things work now has changed but the general
principals haven't.

Gus "How did I get this old?" Wirth

[Kevin Keane Subscription]

Wayland is a *local* display server. xorg is a *network* display server.

 
Wayland covers the most common use case, where the client and the server are running on the same workstation. But as soon as you try to run a remote X11 application, say, from a headless server, you are back to the X11 protocol, and, at least on the display client side, xorg.

 
Sent from Mail for Windows 10

 
From: Dante Lanznaster <mailto:***@gmail.com>
Sent: Thursday, March 1, 2018 12:30 AM
To: Main Discussion List for KPLUG <mailto:kplug-***@kernel-panic.org>
Subject: Re: Finding commit history of a specific kernel module: i915

 


Huh? Both Wayland and X11 (xorg) are display servers. They have their
differences, but AFAIK Wayland came to replace X11, even though it's not
there yet.

On Wed, Feb 28, 2018 at 9:20 PM, Kevin Keane Subscription <

Post by Kevin Keane Subscription
Aside from Gus’ comments, IIRC, Wayland isn’t intended to replace, but
complement xorg. Wayland is for local display rendering, while xorg will
remain relevant for remote sessions.
There also is a question about inertia. For better or for worse, we’ve
seen an increasing resistance and inertia against replacing familiar
fundamental technologies. Not just on Linux, but throughout IT. There still
is a lot of pushback against systemd, six years after the international
IPv6 day, it is on life support outside the mobile space and a few niches,
Unity has actually died, even Microsoft had to backpedal on the tiled UI,
and so on.
With that in mind, I give Wayland only a 50% chance of catching on.
Sent from Mail for Windows 10
Sent: Wednesday, February 28, 2018 8:26 AM
Subject: Re: Finding commit history of a specific kernel module: i915
Before you go about messing with an xorg.conf,
You might consider a Wayland implementation.
At least in openSUSE, the various Desktops are pushing as hard as they
can to replace sorg with Wayland.
But don't hold your breath too much about Wayland....
We've only had a pretty solid KDE Wayland implementation now for about
6 months, and that was after early steps in our Enlightenment Desktop
about 2 years ago.
And, no matter the Desktop, Wayland still lacks features... perhaps
most noticeably, does not support remote X sessions, so in those cases
an xorg x-server has to be running (typically side by side with
Wayland).
Despite the slow progress, IMO Wayland will eventually replace xorg,
so particularly if for instance your preferred distro is Fedora,
you'll probably see Wayland sooner than not, and when that happens
your xorg.conf work will be obsolete.
Yeah, I know how hard it can be to decide how much to invest in a soon
to be deprecated technology before its replacement might be ready, but
that's life sometimes.
Tony

Post by Gus Wirth

Post by David Brown

Post by Brad Beyenhof

Post by Gus Wirth
Is there any way to get a commit history for only a single module?
I'm not familiar enough with git to know if that can be done and
there doesn't seem to be a web interface to let me see what's been
going on. Otherwise I'll just have to build a few kernels to find
out what happened.

If you clone the Linux source and can find the specific directory or
file, you can 'git log $PATH' to get the history of commits that
refer to just the specified files.

One caveat to this is that sometimes things are moved around in the
kernel.  `git log` has a `--follow` argument tha tries to follow this.
I tried this on the 915 driver and it didn't seem to follow much, so,
      $ git log drivers/gpu/drm/i915
      ...
      commit c0e09200dc0813972442e550a5905a132768e56c
      Date:   Thu May 29 10:09:59 2008 +1000
          drm: reorganise drm tree to be more future proof.
and this is the last this command shows, with the drm tree being
      $ git show --stat c0e09200dc
      ...
       drivers/{char/drm => gpu/drm/i915}/i915_dma.c           |  0
So, it looks like this patch made it easier by putting all of the i915
drivers in their own directory.
      $ git log drivers/char/drm/i915'*'
      ...
      commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (tag: v2.6.12-rc2)
      Date:   Sat Apr 16 15:20:36 2005 -0700
          Linux-2.6.12-rc2
               Initial git repository build. I'm not bothering with the
full history,
At this point, we have the first commit that was entered into git.  If
you need history beyond this, there are people who have build other
git repos holding earlier history (reconstructed from releases).  But,
2005 is usually early enough to find most things.

Thanks for the tips. I tried looking at the commits to the i915 module

but

Post by Gus Wirth
it was overwhelming so I wound up doing a bisect on the kernel. After
commit dc911f5bd8aacfcf8aabd5c26c88e04c837a938e
Date:   Wed Aug 9 12:48:53 2017 -0700
     drm/i915/edp: Allow alternate fixed mode for eDP if available.
...
Searching for this commit on the Internet reveals that this has been a

known

Post by Gus Wirth
problem since August 2017 when the commit was initially made, but there
doesn't seem to be much interest in fixing it.
The work around is to to create a custom mode entry in

/etc/X11/xorg.conf.d/

Post by Gus Wirth
that describes the laptop display panel (monitor) and binds it to the
driver.
It's been awhile since I've had to create xorg.conf entries so I was
surprised that instead of having a specific driver for the GPU (intel) it
uses a generic "modesetting" driver that talks to the kernel modesetting
module, i915 in this case. I may have to dig out my old X Windows

lecture,

Post by Gus Wirth
give it an update and do a presentation.
Gus
--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

--
KPLUG-***@kernel-panic.org
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list