On 8 August 2014 02:00, David Herrmann wrote:
> Hi
>
> On Thu, Aug 7, 2014 at 3:04 PM, Chris Wilson
> wrote:
>> Despite the claims of
>>
>> commit 48ba813701eb14b3008edefef4a0789b328e278c
>> Author: David Herrmann
>> Date: Tue Jul 22 18:46:09 2014 +0200
>>
>> drm: drop redundant drm_file-
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140808/254540ba/attachment.html>
On 2014? 08? 07? 22:55, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 22:17, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
On 2014? 08? 07? 20:09, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 0
On 08.08.2014 00:55, Alex Deucher wrote:
>
> Note that there is no PFP (or CE) on the compute queues so we can't
> use PFP (or CE) for compute.
AFAICT cik_hdp_flush_cp_ring_emit() always uses the PFP though.
> Note also that the engine bit is not always consistent (for some packets 0
> = ME, 1
ail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140808/aeada4a9/attachment.html>
abled. So
> >>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
> >>>>>> host controller should be disabled.
> >>>>>
> >>>>> No. I don't think any transmissions can happen when all lanes are in
> >>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
> >>>>> should be transmitted in low power mode (see LP Transmission in 2.1
> >>>>> "Definitions" of the MIPI DSI specification).
> >>>>>
> >>>>
> >>>> Hm.. I see. I meant,
> >>>>
> >>>> if (flags & MIPI_DSI_MSG_USE_LPM)
> >>>>disable HS clock <- required.
> >>>>
> >>>> transmit command data <- in LPM.
> >>>
> >>> No. Disabling the HS clock is not required for LPM mode. In fact if the
> >>> peripheral specifies that it doesn't support non-continuous mode then
> >>> the HS clock must *never* be disabled as long as the peripheral is in
> >>> use.
> >>>
> >>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
> >>> need to be considered separately.
> >>
> >> I mentioned already LPM and NON_CONTINUOUS are unrelated.
> >>
> >> It seems that you say the only way to transfer command data in LPM is
> >> non-continuous clock mode.
> >
> > No, that's not what I'm saying.
> >
> >> However, you said and also the spec says, "Non-continuous mode simply
> >> means that the clock lane enters LP-11 between HS transmissions".
> >> Doesn't *between HS transmissions" mean the command data is transmitted
> >> in HS, *not in LPM*, and clock lane enters LP-11 between them?
> >
> > Not necessarily. You can transmit command packets in high-speed mode,
> > but you don't have to. If you transmit packets in low power mode, then
>
> That would may why we are mentioning same comments repeatedly.
>
> In my case, host driver waits for the lane stop state (LP-11), and then
> disables HS clock to transmit command data in LPM. Of course, I'm not
> sure that yet it's correct way.
That's confusing. How can the lane go to LP-11 when the clock is still
running?
> In Tegra, What to do for it?
There are two bits in two separate registers for this:
DSI_HOST_CONTROL:
bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
packets
- 0 = LOW: low speed
- 1 = HIGH: high speed
DSI_CONTROL:
bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
- 0 = CONTINUOUS: HS clock is on all the time
- 1 = TX_ONLY: HS clock is only active during HS
transmissions
So if the peripheral supports non-continuous mode of operation we set
the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
remains on all the time.
When a packet is to be transmitted in high speed mode, we set the
DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
cleared.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140808/e120cc7a/attachment-0001.sig>
On 08/07/2014 10:54 AM, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 10:39:36AM +0200, Andrzej Hajda wrote:
>> On 08/07/2014 09:25 AM, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 08:53:47AM +0200, Andrzej Hajda wrote:
Hi Thierry,
Nice case.
On 08/05/2014 05:39 PM,
On 2014? 08? 08? 16:03, Thierry Reding wrote:
> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 22:55, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
On 2014? 08? 07? 22:17, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 1
s scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140808/a2700b20/attachment.html>
Hi,
This series adds a page flipping implementation using qxl_draw_dirty_fb and
prime support. Similar to the vmware driver it assumes that there is no other
virtual device to share buffers with.
Andreas Pokorny (2):
Simple crtc page flipping emulated using buffer copy
Enables gem prime help
Signed-off-by: Andreas Pokorny
---
drivers/gpu/drm/qxl/qxl_display.c | 49 +++
drivers/gpu/drm/qxl/qxl_drv.c | 18 ++
drivers/gpu/drm/qxl/qxl_kms.c | 16 +
3 files changed, 79 insertions(+), 4 deletions(-)
diff --git a/drivers/g
As there should not be any other virtual device that might share buffers,
the callbacks remain empty stubs. Still prime can be used to transfer buffers
between processes that use qxl.
Signed-off-by: Andreas Pokorny
---
drivers/gpu/drm/qxl/Makefile| 2 +-
drivers/gpu/drm/qxl/qxl_drv.c | 13
>>> On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher
>>> wrote:
We should be using PFP as much as possible. Does the attached patch help?
> Unfortunately not.
Maybe add a readback of the VM base addr pointer to make sure that the
write has really reached the SBRM?
Otherwise I'm out of ideas
From: Michel D?nzer
This fixes a ring test failure reported on a Kabini system which was
triggered by write-combined CPU mappings of the ring buffers.
Reported-and-Tested-by: Will Trives
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_ring.c | 4
1 file changed, 4 insertio
On 08.08.2014 17:44, Christian K?nig wrote:
On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher
wrote:
> We should be using PFP as much as possible. Does the attached
> patch help?
>> Unfortunately not.
>
> Maybe add a readback of the VM base addr pointer to make sure that the
> write
On 08/08/2014 09:37 AM, Inki Dae wrote:
> On 2014? 08? 08? 16:03, Thierry Reding wrote:
>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
>>> On 2014? 08? 07? 22:55, Thierry Reding wrote:
On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
> On 2014? 08? 07? 22:17, Thierry
From: Thierry Reding
Commit 21d70354bba9 ("drm: move drm_stub.c to drm_drv.c") moves the code
from drm_stub.c into drm_drv.c. Update DocBook to include that instead.
Signed-off-by: Thierry Reding
---
Documentation/DocBook/drm.tmpl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
> On 08/08/2014 09:37 AM, Inki Dae wrote:
>> On 2014? 08? 08? 16:03, Thierry Reding wrote:
>>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
On 2014? 08? 07? 22:55, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 10:39:29PM +0900, In
;
> >>>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
> >>>>> peripheral specifies that it doesn't support non-continuous mode then
> >>>>> the HS clock must *never* be disabled as long as the peripheral is in
> >>>>> use.
> >>>>>
> >>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
> >>>>> need to be considered separately.
> >>>>
> >>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
> >>>>
> >>>> It seems that you say the only way to transfer command data in LPM is
> >>>> non-continuous clock mode.
> >>>
> >>> No, that's not what I'm saying.
> >>>
> >>>> However, you said and also the spec says, "Non-continuous mode simply
> >>>> means that the clock lane enters LP-11 between HS transmissions".
> >>>> Doesn't *between HS transmissions" mean the command data is transmitted
> >>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
> >>>
> >>> Not necessarily. You can transmit command packets in high-speed mode,
> >>> but you don't have to. If you transmit packets in low power mode, then
> >>
> >> That would may why we are mentioning same comments repeatedly.
> >>
> >> In my case, host driver waits for the lane stop state (LP-11), and then
> >> disables HS clock to transmit command data in LPM. Of course, I'm not
> >> sure that yet it's correct way.
> >
> > That's confusing. How can the lane go to LP-11 when the clock is still
> > running?
>
> Actually, we are doing so. If the clock is still running then dsi driver
> will wait for stop state of the clock and data lanes. Know that this is
> valid only when initial time - just one time since power up.
>
> /* Check clock and data lane state are stop state */
> timeout = 100;
> do {
> if (timeout-- == 0) {
> dev_err(dsi->dev, "waiting for bus lanes timed out\n");
> return -EFAULT;
> }
>
> reg = readl(dsi->reg_base + DSIM_STATUS_REG);
> if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
> != DSIM_STOP_STATE_DAT(lanes_mask))
> continue;
> } while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
>
> >
> >> In Tegra, What to do for it?
> >
> > There are two bits in two separate registers for this:
> >
> > DSI_HOST_CONTROL:
> > bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
> >packets
> > - 0 = LOW: low speed
> > - 1 = HIGH: high speed
> >
> > DSI_CONTROL:
> > bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
> > - 0 = CONTINUOUS: HS clock is on all the time
> > - 1 = TX_ONLY: HS clock is only active during HS
> >transmissions
> >
> > So if the peripheral supports non-continuous mode of operation we set
> > the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
> > remains on all the time.
> >
> > When a packet is to be transmitted in high speed mode, we set the
> > DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
> > cleared.
>
> That is exactly what I want. In your case, if you want to transmit
> command data in Low Power Mode in case of supporting non-continuous
> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
> would clear DSI_HIGH_SPEED_TRANS (LOW).
>
> So I guess,
>
> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
> disable DSI_HIGH_SPEED_TRANS; <- LOW
> enable DSI_HS_CLK_CTRL; <- TX_ONLY
> }
>
> transmit command data <- in LPM.
>
> However, what if the peripheral doesn't support non-continuous but want
> to transmit command data in LPM? Is that impossible?
The above is actually more like this:
if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
clear DSI_HS_CLK_CTRL;
else
set DSI_HS_CLK_CTRL;
if (msg->flags & MIPI_DSI_MSG_USE_LPM)
clear DSI_HIGH_SPEED_TRANS;
else
set DSI_HIGH_SPEED_TRANS;
So for peripherals that don't support non-continuous clock mode, this
will result in the following for low-power transmissions:
clear DSI_HS_CLK_CTRL; /* HS clock always on */
clear DSI_HIGH_SPEED_TRANS;
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140808/84b8af1e/attachment-0001.sig>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140808/ae735a80/attachment.html>
w if it's worth the trouble. Anyway, it would be good to hear
thoughts on this from the device tree maintainers.
> >> I am not sure if it is better. If you do not like video
> >> interfaces
> >> maybe better would be sth like this:
> >>
> >>dsi at 5430 {
> >>panel: panel at 0 {
> >>compatible = "sharp,lq101r1sx01";
> >>reg = <0>;
> >>secondary_dsi = <&dsiB>;
> >>};
> >>};
> >>
> >>dsiB: dsi at 5440 {
> >>};
> > That's pretty much the same thing that I proposed, except that it
> > reverses the link between the two.
> For me it is fundamentally different - in your proposition you have two
> different panels, in my you have only one, attached to one dsi with
> phandle to 2nd dsi.
Looking at the example again I don't see how it could work. The phandle
references the second DSI host, but we need a reference to the second
DSI peripheral. We can't just assume that it's on the same virtual
channel as the first.
> > In fact I tried something similar to
> > that before, but it has a couple of problems: if the secondary device
> > does not have a compatible string (that's probably not valid in device
> > tree to begin with) then there's no way for the device to report what
> > format it expects or what number of lanes it uses. But those are
> > parameters that are needed to set up the DSI (and display controllers).
>
> I2C has:
> struct i2c_client *
> i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
>
> DSI could have something similar, this way you could pass everything you
> need.
We don't need any of that if both devices have a proper compatible
string, which they should have anyway, since then the driver can fill in
those values as appropriate.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140808/2655c561/attachment.sig>
Hi
On Wed, Aug 6, 2014 at 9:10 AM, Daniel Vetter wrote:
> The current refcounting scheme is that the fb lookup idr also holds a
> reference. This works out nicely bacause thus far we've always
> explicitly cleaned up idr entries for framebuffers:
> - Userspace fbs get removed in the rmfb ioctl or
Hi
On Fri, Aug 8, 2014 at 11:33 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> Commit 21d70354bba9 ("drm: move drm_stub.c to drm_drv.c") moves the code
> from drm_stub.c into drm_drv.c. Update DocBook to include that instead.
>
> Signed-off-by: Thierry Reding
Nice catch.
Reviewed-by: Da
From: Thierry Reding
kerneldoc doesn't know how to parse variables, so don't let it try.
Signed-off-by: Thierry Reding
---
drivers/dma-buf/fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
index 4222cb2aa96a..7bb9d65d9
From: Thierry Reding
The seqno_fence_init() function's cond argument isn't described in the
kerneldoc comment. Fix that to silence a warning when building DocBook
documentation.
Signed-off-by: Thierry Reding
---
include/linux/seqno-fence.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/in
I started looking through the code week or so ago.
No much progress though but could you explain meaning of this to me:
if (running == 0) {
if (running) {
blackout = RREG32(MC_SHARED_BLACKOUT_CNTL);
WREG32(MC_SHARED_BLACKOUT_CNTL, blackout | 1);
}
...
It's in si.c, line 15
On Fri, Aug 8, 2014 at 4:50 AM, Michel D?nzer wrote:
> On 08.08.2014 17:44, Christian K?nig wrote:
> On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher
> wrote:
>> We should be using PFP as much as possible. Does the attached
>> patch help?
>>> Unfortunately not.
>>
>> Maybe add a read
On Fri, Aug 8, 2014 at 9:31 AM, Alex Deucher wrote:
> On Fri, Aug 8, 2014 at 4:50 AM, Michel D?nzer wrote:
>> On 08.08.2014 17:44, Christian K?nig wrote:
>> On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher
>> wrote:
>>> We should be using PFP as much as possible. Does the attached
>
On Fri, Aug 8, 2014 at 12:35 PM, David Herrmann
wrote:
> Ewww, this is ugly. You now make the unregistration dynamic and it's
> no longer under driver control. The typical device-control flow
> assumes there's an authority that controls at which point objects are
> registered and unregistered. Yo
On Fri, Aug 8, 2014 at 4:45 AM, Michel D?nzer wrote:
> From: Michel D?nzer
>
> This fixes a ring test failure reported on a Kabini system which was
> triggered by write-combined CPU mappings of the ring buffers.
>
> Reported-and-Tested-by: Will Trives
> Signed-off-by: Michel D?nzer
Applied to
Hi Dave,
So I heard that proper pull requests have a revert on top ;-) So here we
go with my usual mid-merge-window pile of fixes.
Big fix is the duct-tape for ring init on g4x platforms, we seem to have
found the magic again to make those machines as happy as before (not
perfect though unfortuna
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140808/2b649f23/attachment.html>
On 06 Aug 04:47 PM, Jyri Sarha wrote:
> Add external clock provaider for am33xx devices.
Typo: s/provaider/provider
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
Hi all,
there is a rather severe performance problem i accidentally found when
trying to give Linux 3.16.0 a final test on a x86_64 MacBookPro under
Ubuntu 14.04 LTS with nouveau as graphics driver.
I was lazy and just installed the Ubuntu precompiled mainline kernel.
That kernel happens to ha
Static analysis will be unhappy if a function can theoretically return
0 and we're trying to divide by that value.
Mark that case that cannot occur as a BUG() instead.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Static analysers find it 'suspicious', that we're trying to allocate memory for
elements of size sizeof(struct drm_fb_helper_connector) when the array is
defined as struct drm_fb_helper_connector **.
Use sizeof(struct drm_fb_helper_connector *) instead.
Note that the structure being defined as:
Hello Jyri,
On 06 Aug 04:47 PM, Jyri Sarha wrote:
> The code has a functional dependency to:
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg108199.html
>
> Without the above patch the audio card does not probe.
>
> The code has been rebased on top of Linux 3.16 merged with
> git
On Fri, Aug 8, 2014 at 7:34 AM, Daniel Vetter wrote:
>
> git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-08-08
Hmm. My laptop no longer resumes properly.
Or rather, I suspect it resumes, but the screen is black.
I will bisect, and I *will* revert if I find the offending comm
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140808/cc2b0b79/attachment.html>
On Fri, Aug 8, 2014 at 12:19 PM, Linus Torvalds
wrote:
> On Fri, Aug 8, 2014 at 7:34 AM, Daniel Vetter
> wrote:
>>
>> git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-08-08
>
> Hmm. My laptop no longer resumes properly.
The problem seems to exist already with just the plain d
On Fri, Aug 8, 2014 at 12:37 PM, Linus Torvalds
wrote:
>
> The problem seems to exist already with just the plain drm pull from
> Dave. I thought I had tested that, but apparently not.
Still busy bisecting (and it's going into the i915 part of Dave's drm
pull, so the bisect looks sane so far), bu
On Fri, Aug 8, 2014 at 10:30 AM, Linus Torvalds
wrote:
>
> This is a Sony Vaio Pro 11, so it's bog-standard intel graphics (Haswell ULT).
Got this while bisecting. I'm not sure it's related, the behavior was
a bit different from the other cases. So I'll try to continue
bisecting, but am a bit wor
On Fri, Aug 8, 2014 at 1:52 PM, Linus Torvalds
wrote:
>
> Got this while bisecting. I'm not sure it's related
It's not.
The actual bug was panel self refresh. It's still broken, and doesn't
work. So enabling it by default was a big mistake (commit
b6d547791fd3: "drm/i915: Enable PSR by default."
From: Sonika Jindal
Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_4
From: Sonika Jindal
Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_4
From: Sonika Jindal
Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_1
From: Sonika Jindal
Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_4
From: Sonika Jindal
Rename the defines to have levels instead of values for vswing and pre-emph
levels as the values may differ in other scenarios like low vswing of eDP 1.4
where the values are different.
Updated in all the drivers as well
v2: Keeping the old defines in first patch and removing
From: Sonika Jindal
Adding new defines, older one will be removed in the last patch in the series.
This is to rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
D
From: Sonika Jindal
Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.
Done using following cocci patch for each define:
@@
@@
# define DP_TRAIN_VOLTAGE_SWING_4
From: Sonika Jindal
This is the last patch in the series, so remove old defines
Signed-off-by: Sonika Jindal
---
include/drm/drm_dp_helper.h |8
1 file changed, 8 deletions(-)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 3840a05..9305c71 100644
---
Hi!
I recetly repurposed a BlueMedia OPTIMA II system, Biostar MCP6P M2+
mainboard, AMD Athlon II X2 215 with 2700 MHz, 8 GiB RAM, Xen setup, for
use as a desktop machine (the Xen dom0, specifically). I put in a
Sapphire Radeon HD 4350 card where I'm connecting the DVI output to a
portrait-orient
52 matches
Mail list logo
