Re: [openchrome-devel] DRI2 support ?

2021-02-16 Thread Xavier Bachelot 

Le 08/02/2021 à 23:31, Xavier Bachelot a écrit :

Hi Kevin,

Fedora 34 Xserver has DRI 1 support disabled, and openchrome fails to 
compile in such a case, as DRI support is auto-enabled in openchrome 
because libdrm is dragged in as a dependency of the Xserver.


Does openchrome still only support DRI1 ? Or is there support for DRI2 ? 
In case only DRI 1 is supported, I guess a --disable-dri compile option 
could do, but there is no such option currently.


Indeed, there is a --disable-dri compile option, as soon as I'm using a 
snapshot from the 'main' branch rather than the one I was generating 
from the now stale 'master' branch.

Sorry for the noise... :-(

Anyway, the DRI2+ support question is still open. Is that something that 
is on your todo ?


Regards,
Xavier

___
openchrome-devel mailing list
openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[openchrome-devel] DRI2 support ?

2021-02-08 Thread Xavier Bachelot 

Hi Kevin,

Fedora 34 Xserver has DRI 1 support disabled, and openchrome fails to 
compile in such a case, as DRI support is auto-enabled in openchrome 
because libdrm is dragged in as a dependency of the Xserver.


Does openchrome still only support DRI1 ? Or is there support for DRI2 ? 
In case only DRI 1 is supported, I guess a --disable-dri compile option 
could do, but there is no such option currently.


Regards,
Xavier
___
openchrome-devel mailing list
openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

Re: [openchrome-devel] Build failure with GCC 10

2020-02-21 Thread Xavier Bachelot 

Hi Kevin,

Le 20/02/2020 à 23:07, Kevin Brace a écrit :

Hi Xavier,

I have not heard from you for a while.
How have you been?


I'm doing fine, thanks. I'm quite busy with life in general, and part of 
both my pro and spare time is quite full with various opensource stuff. 
Unfortunately not much of it is dedicated to openchrome, and I'm now 
left with only one x86_64 machine still able to run openchrome, due to 
lot of distros dropping i386 support, which most of my VIA boards are. 
However, I still keep an eye on what is going on here and I still take 
care of the very first package I pushed to Fedora, which is the 
openchrome driver :-)



Xavier, for this issue, can you open a bug report with 
https://bugs.freedesktop.org?
I do not really use the latest compiler for testing, so I was not aware of this 
issue.
You will need to attach a text file with relevant error messages indicating 
which extern variables are causing the issue.


This issue is only visible with GCC 10, and I don't think any stable 
distro ships with it yet. I'm seeing this on Fedora 32, which has not 
even reached beta, so I'm probably the first one to notice.


Actually, I thing the behavior can be reproduced with any GCC version. 
GCC 10 enabled -fno-common by default, but this flag is available in 
earlier GCC as well, so one can reproduce the GCC 10 behavior easily.
For the same reason, the build failure can be worked around quite easily 
too with GCC 10.


The errors are like :
/usr/bin/ld: 
.libs/via_exa.o:/builddir/build/BUILD/xf86-video-openchrome-20200131/src/via_driver.h:365: 
multiple definition of `iga2_crtc_funcs'; 
.libs/via_analog.o:/builddir/build/BUILD/xf86-video-openchrome-20200131/src/via_driver.h:365: 
first defined here


/usr/bin/ld: 
.libs/via_exa.o:/builddir/build/BUILD/xf86-video-openchrome-20200131/src/via_driver.h:364: 
multiple definition of `iga1_crtc_funcs'; 
.libs/via_analog.o:/builddir/build/BUILD/xf86-video-openchrome-20200131/src/via_driver.h:364: 
first defined here


/usr/bin/ld: 
.libs/via_exa.o:/builddir/build/BUILD/xf86-video-openchrome-20200131/src/via_vt1632.h:54: 
multiple definition of `via_vt1632_funcs'; 
.libs/via_analog.o:/builddir/build/BUILD/xf86-video-openchrome-20200131/src/via_vt1632.h:54: 
first defined here


Grepping the build log, the affected vars are :
iga1_crtc_funcs
iga2_crtc_funcs
via_sii164_funcs
via_vt1632_funcs

I will drop all of that in a proper bug report with full build log asap.

I'm attaching a quickly hacked patch that fixes the link issue, but I'm 
not confident it's okay. Only build tested, not run tested anyway. the 
patch is against 0.6.209, I'll submit a proper patch once you've looked 
at it and I've tested for real.


Regards,
Xavier




Regards,

Kevin Brace
Brace Computer Laboratory blog
https://bracecomputerlab.com



Date: Mon, 17 Feb 2020 18:21:05 +0100
From: Xavier Bachelot 
To: openchrome-devel@lists.freedesktop.org
Subject: [openchrome-devel] Build failure with GCC 10
Message-ID: 
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Kevin,

openchrome fails to link when using GCC 10 which now defaults to
-fno-common, as explained here:
https://gcc.gnu.org/gcc-10/porting_to.html#common

Regards,
Xavier



___
openchrome-devel mailing list
openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel



diff -Naur xf86-video-openchrome-20200131.orig/src/via_driver.h xf86-video-openchrome-20200131/src/via_driver.h
--- xf86-video-openchrome-20200131.orig/src/via_driver.h	2020-02-21 10:52:01.523263642 +0100
+++ xf86-video-openchrome-20200131/src/via_driver.h	2020-01-23 01:27:57.0 +0100
@@ -361,8 +361,8 @@
 void viaProcessOptions(ScrnInfoPtr pScrn);
 
 /* In via_display.c. */
-const xf86CrtcFuncsRec iga1_crtc_funcs;
-const xf86CrtcFuncsRec iga2_crtc_funcs;
+extern xf86CrtcFuncsRec iga1_crtc_funcs;
+extern xf86CrtcFuncsRec iga2_crtc_funcs;
 
 /* In via_exa.c. */
 Bool viaInitExa(ScreenPtr pScreen);
diff -Naur xf86-video-openchrome-20200131.orig/src/via_sii164.h xf86-video-openchrome-20200131/src/via_sii164.h
--- xf86-video-openchrome-20200131.orig/src/via_sii164.h	2020-02-21 10:52:52.587481902 +0100
+++ xf86-video-openchrome-20200131/src/via_sii164.h	2020-01-23 01:27:57.0 +0100
@@ -51,7 +51,7 @@
 } viaSiI164Rec, *viaSiI164RecPtr;
 
 
-const xf86OutputFuncsRec via_sii164_funcs;
+extern xf86OutputFuncsRec via_sii164_funcs;
 
 Bool viaSiI164Probe(ScrnInfoPtr pScrn, I2CBusPtr pI2CBus);
 void viaSiI164Init(ScrnInfoPtr pScrn);
diff -Naur xf86-video-openchrome-20200131.orig/src/via_vt1632.h xf86-video-openchrome-20200131/src/via_vt1632.h
--- xf86-video-openchrome-20200131.orig/src/via_vt1632.h	2020-02-21 10:53:44.302702683 +0100
+++ xf86-video-openchrome-20200131/src/via_vt1632.h	2020-01-23 01:27:57.0 +0100
@@ -51,7 +51,7 @@
 } viaVT1632Rec, *viaVT1632RecPtr;
 
 
-const xf86OutputFuncsRec via_vt1632_funcs;
+extern xf86OutputFuncsRec

Re: [Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop

2017-03-21 Thread Xavier Bachelot 
On 21/03/2017 05:22, Kevin Brace wrote:
> Hi Xavier,
> 
>> Sent: Tuesday, March 21, 2017 at 12:57 AM
>> From: "Xavier Bachelot" <xav...@bachelot.org>
>> To: "Kevin Brace" <kevinbr...@gmx.com>
>> Cc: openchrome-devel@lists.freedesktop.org
>> Subject: Re: [Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop
>>
>> On 20/03/2017 22:38, Xavier Bachelot wrote:
>>> Hi Kevin,
>>>
>>> . . .
>>>
>>> This last paragraph got me thinking, and I just did an interesting
>>> experiment.
>>> I have booted the laptop with a 1280x1024 screen hooked up to the VGA port.
>>> This results in VGA just complaining about unsupported video mode upon
>>> starting X, but the more interesting part is the FP is displaying a
>>> 1280x1024 picture, which is not distorted.
>>> There is garbage on the right, after the 1280 horizontal boundary, which
>>> is very probably a distorted re-print of the beginning of left of the
>>> screen, and the part below the 768 vertical boundary is indeed not
>>> displayed. The cursor cannot go after the 1280 horizontal boundary, and
>>> gets vertically duplicated when going below the 768 vertical boundary.
>>>
>>> I've tried to use xrandr, but that doesn't help.
>>> X log, regs dump and xrandr output attached.
>>>
>>> Does that ring any bell ?
>>>
>>> I'm now going to compare this regs dump with the ones I took before, and
>>> then try to poke at registers without the VGA port attached.
>>>
>>> Regards,
>>> Xavier
>>>
>> I thought I was running with patch v3 applied, but this is actually
>> vanilla 0.6.0 with only the 1366x768 panel fix added, sorry for the bad
>> info.
>>
>> Anyway, it seems initializing IGA1 for VGA, together with IGA2 for FP,
>> helps getting a proper display on the FP.
>>
>> Regards,
>> Xavier
>>
> 
> I just committed the previously mentioned changes, but are you now saying 
> that the FP is now properly working?

FP does work with vanilla 0.6.0 + the panel fix for 1366x768, if and
only if VGA is connected. VGA on the other hand doesn't work in this setup.
Sorry again for sending wrong information in the first place, and being
inaccurate.

> The code I pushed is now at Version 0.6.100.
> It has the updated mode setting code for VX855 and VX900 chipsets, and it 
> also has the VIA panel ID 10 (0xA) fix as well.
> The code I pushed does not have the software based FP power on / off code.
> If the FP is now working properly, I am happy to hear that, but if necessary, 
> I can also push the code tweaks to use software based FP power on / off code 
> for VX855 and VX900 chipsets as well.

I will retry with git master, but it didn't work properly with version 2
of your patch, even with VGA connected. In this case, FP is showing the
distorted picture, and VGA is reported as using an incorrect resolution,
so there is still something to fix.

That may be related to panel scaling, which you said is only available
on IGA2, and is reported as enabled by via_reg_dump.

If you look at the regs dumps for 0.6 + panel fix with FP + VGA, you'll
see the vertical resolution for IGA1/VGA is the one from the FP (768),
not the one from the external screen (1024). 1280x768 is most probably
not a supported resolution, which would explain.

If you have the time, please send a patch adding the use of software
power sequence, I'll check if it helps or not.

> There weren't too many laptops with VX855 and VX900 chipsets produced (i.e., 
> VIA's small niche of low cost / power market was being eroded by Intel Atom 
> processors around Year 2009 to 2011), but VIA did have several in house 
> mini-ITX mainboards with a LVDS FP connector, so I will like to make sure 
> that FP works.
> If the iDOT Computers L740 laptop's FP is now properly working, then I can 
> work on merging your code fixes you have committed to "fix_warning" branch.
> I personally have never done code merging from one branch to another, so if 
> you want me to do it, let me know the git command line example for doing it.
> Otherwise, I can manually commit them myself with you being the author of all 
> of the commits.
> Personally, I am fine with all of the 6 commits you have made so far in your 
> "fix_warning" branch.
> 
I'll push them myself after adding your reviewed-by.
I will not push the last one which is adding -Wno-unused-functions.
Instead, I'll send a proper patch removing the unused-functions warning
for you to review. I don't want to risk removing functions that may
still have some use later, without you first double-checking that's it's
ok, or even hiding an otherwise useful warning.

Regards,
Xavier
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

Re: [Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop

2017-03-20 Thread Xavier Bachelot 
On 20/03/2017 22:38, Xavier Bachelot wrote:
> Hi Kevin,
> 
> On 20/03/2017 03:29, Kevin Brace wrote:
>> Hi Xavier,
>>
>> These are things I will like to do moving forward.
>> I will like to commit a few things into the master branch.
>> They are,
>>
>> 1) Updated mode setting code for VX855 and VX900 chipset
>> 2) Replacing the wrong VIA Panel Index 10 with 1366 x 768
>> 3) Addition of two helper functions
>>
>> For 1 and 2, I will add your name as "Signed-off-by < . . . >" in order to 
>> give you credit.
>> I hope you can agree to this.
>> I will not commit the power on / off code for now.
> 
> Fine by me.
> 
>> After this is done, then it will be easier to perform experiments with 
>> temporarily assigning IGA1 to FP and IGA2 to VGA.
>> Theoretically, if the code is written correctly, both settings should work 
>> fine.
>> As for my own equipment, OpenChrome Version 0.6 worked fine on ECS VX900-I 
>> mainboard when VGA was assigned to IGA1, and I utilized 1680 x 1050 
>> resolution.
>> After the code commit is done, I will try to assign IGA2 for VGA to see how 
>> VX900-I mainboard performs.
>>
> This last paragraph got me thinking, and I just did an interesting
> experiment.
> I have booted the laptop with a 1280x1024 screen hooked up to the VGA port.
> This results in VGA just complaining about unsupported video mode upon
> starting X, but the more interesting part is the FP is displaying a
> 1280x1024 picture, which is not distorted.
> There is garbage on the right, after the 1280 horizontal boundary, which
> is very probably a distorted re-print of the beginning of left of the
> screen, and the part below the 768 vertical boundary is indeed not
> displayed. The cursor cannot go after the 1280 horizontal boundary, and
> gets vertically duplicated when going below the 768 vertical boundary.
> 
> I've tried to use xrandr, but that doesn't help.
> X log, regs dump and xrandr output attached.
> 
> Does that ring any bell ?
> 
> I'm now going to compare this regs dump with the ones I took before, and
> then try to poke at registers without the VGA port attached.
> 
> Regards,
> Xavier
> 
I thought I was running with patch v3 applied, but this is actually
vanilla 0.6.0 with only the 1366x768 panel fix added, sorry for the bad
info.

Anyway, it seems initializing IGA1 for VGA, together with IGA2 for FP,
helps getting a proper display on the FP.

Regards,
Xavier
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

Re: [Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop

2017-03-16 Thread Xavier Bachelot 

Hi Kevin,

On 15/03/2017 23:33, Kevin Brace wrote:

Try this third version of the patch.
I changed the FP power on / off code to use software controlled method already 
proven with CX700 / VX700 and VX800 chipsets.

No improvement over patch v2 with patch v3. I haven't collected neither 
log nor regs dump though.


I started to poke at register manually after applying v2 the other day, 
but no luck. Is there any specific range of registers that are more 
likely than others to help ?


Would a picture of the distorted screen, together with a picture of how 
it should look like, help ? I don't know how to describe the distortion, 
a picture is worth a thousand word :-) The display is compressed in the 
top third or half of the screen, and diagonally stretched to the right. 
The remaining bottom part of the screen seems like uninitialized memory. 
It seems like the framebuffer is using a different horizontal resolution 
than the display. Could it be something like wrong "pitch" ?


Regards,
Xavier
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

Re: [Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop

2017-03-16 Thread Xavier Bachelot 

Hi Kevin,

On 15/03/2017 04:56, Kevin Brace wrote:

It appears that 3X5.3B through 3X5.3F contain weird values.
Why is this?

   3d5.3b = 0x0b (Scratch Pad 2)
   3d5.3c = 0x00 (Scratch Pad 3)
   3d5.3d = 0x00 (Scratch Pad 4)
   3d5.3e = 0x00 (Scratch Pad 5)
   3d5.3f = 0x00 (Scratch Pad 6)

The log from yesterday prior to applying the patch (Version 2 of the patch) 
shows the proper values.

   3d5.3b = 0x03 (Scratch Pad 2)
   3d5.3c = 0x08 (Scratch Pad 3)
   3d5.3d = 0xa4 (Scratch Pad 4)
   3d5.3e = 0x00 (Scratch Pad 5)
   3d5.3f = 0x0a (Scratch Pad 6)


I've seen this happen once yesterday, likely with version 2 of the 
patch, but couldn't reproduce, with either version 2 or version 3.
I thought at first it could be related to DPMS, but cannot confirm, as I 
couldn't reproduce.
I'll try to keep this point in mind when doing more test, but it doesn't 
seem to be very frequent, so probably not that important at the moment.


Regards,
Xavier
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

Re: [Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop

2017-03-14 Thread Xavier Bachelot 
Hi,

I came up with almost the same patch after some digging into the VX900
manual minutes before you sent yours. I guess it took you way less time
than me though :-)

So, back at the distorted image, with a working pointer now, I'm not
sure it was there previously.
Log and dump attached.

Regards,
Xavier


On 15/03/2017 00:49, Kevin Brace wrote:
> Hi Xavier,
> 
> Sorry for the implicit function death traps.
> I fixed the problem, and the second version patch should not have the issue.
> 
> Regards,
> 
> Kevin Brace
> The OpenChrome Project maintainer / developer
> 
> 
>> Sent: Tuesday, March 14, 2017 at 3:53 PM
>> From: "Xavier Bachelot" <xav...@bachelot.org>
>> To: "Kevin Brace" <kevinbr...@gmx.com>, 
>> openchrome-devel@lists.freedesktop.org
>> Subject: Re: [Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop
>>
>> On 14/03/2017 23:24, Xavier Bachelot wrote:
>>> Hi Kevin,
>>>
>>> On 14/03/2017 22:33, Kevin Brace wrote:
>>>> Hi Xavier,
>>>>
>>>> Okay, at least some progress.
>>>> I was guessing that LVDS1 was still at IGA1, so switching to IGA2 will 
>>>> correct the problem, but I guess there were still some missing pieces.
>>>> Based on what you reported, I wrote a patch that should now correctly 
>>>> initialize LVDS1 for VX855 and VX900 chipsets.
>>>> It appears that these only have one LVDS channel as opposed to CX700/VX700 
>>>> and VX800 chipsets which appear to have two LVDS channels, to which one of 
>>>> them can be used as DVI.
>>>> I hope the patch works.
>>>>
>>> Thanks for the patch. It may or may not work, I can't tell, as both LVDS
>>> channels are powered down and thus the screen is black.
>>> I've attached the X log and regs dump.
>>>
>> I guess that explains :
>>
>> via_fp.c: In function ‘via_lvds_mode_set’:
>> via_fp.c:1300:13: warning: implicit declaration of function
>> ‘viaLVDS1SetDithering’ [-Wimplicit-function-declaration]
>>  viaLVDS1SetDithering(pScrn, Panel->useDithering ? TRUE :
>> FALSE);
>>  ^~~~
>> via_fp.c:1303:13: warning: implicit declaration of function
>> ‘viaLVDS1SetOutputFormat’ [-Wimplicit-function-declaration]
>>  viaLVDS1SetOutputFormat(pScrn, 0x01);
>>  ^~~
>>
>> Xavier
>>
> 

via-chrome-tool (C) 2009 by VIA Technologies, Inc.
This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY

Sequencer register dump (IO Port address: 0x3c4): 
   3c5.00 = 0x03 (Reset)
   3c5.01 = 0x01 (Clocking Mode)
   3c5.02 = 0x0f (Map Mask)
   3c5.03 = 0x00 (Character Map Select)
   3c5.04 = 0x0e (Memory Mode)
   3c5.10 = 0x01 (Extended Register Unlock)
   3c5.11 = 0x78 (Configuration 0)
   3c5.12 = 0x00 (Configuration 1)
   3c5.13 = 0x00 (Configuration 2 (DVP1 strapping))
   3c5.14 = 0x00 (Frame Buffer Size Control)
   3c5.15 = 0x22 (Display Mode Control)
   3c5.16 = 0x0c (Display FIFO Threshold Control)
   3c5.17 = 0x1f (Display FIFO Control)
   3c5.18 = 0x70 (Display Arbiter Control 0)
   3c5.19 = 0x7f (Power Management)
   0x01 CPU Interface Clock Control: 0x01
   0x02 Display Interface Clock Control: 0x02
   0x04 MC Interface Clock Control: 0x04
   0x08 Typical Arbiter Interface Clock Control: 0x08
   0x10 AGP Interface Clock Control: 0x10
   0x20 P-Arbiter Interface Clock Control: 0x20
   0x40 MIU/AGP Interface Clock Control: 0x40
   3c5.1a = 0x89 (PCI Bus Control)
   0x01 LUT Shadow Access: 0x01
   0x04 PCI Burst Write Wait State Select (0: 0 Wait state, 1: 1 Wait 
state): 0x00
   0x08 Extended Mode Memory Access Enable (0: Disable, 1: Enable): 0x08
   0x40 Software Reset (0: Default value, 1: Reset): 0x00
   0x80 Read Cache Enable (0: Disable, 1: Enable): 0x80
   3c5.1b = 0xf0 (Power Management Control 0)
   0x01 Primary Display's LUT Off: 0x00
   0x18 Primary Display Engine VCK Gating: 0x10
   0x60 Secondary Display Engine LCK Gating: 0x60
   3c5.1c = 0x54 (Horizontal Display Fetch Count Data)
   3c5.1d = 0x00 (Horizontal Display Fetch Count Control)
   3c5.1e = 0x01 (Power Management Control)
   0x01 ROC ECK: 0x01
   0x02 Replace ECK by MCK: 0x00
   0x08 Spread Spectrum: 0x00
   0x30 DVP1 Power Control: 0x00
   0xc0 VCP Power Control: 0x00
   3c5.20 = 0x00 (Typical Arbiter Control 0)
   3c5.21 = 0x18 (Typical Arbiter Control 1)
   3c5.22 = 0x14 (Display Arbiter Control 1)
   3c5.26 = 0x3d (IIC Serial Port Control 0)
   3c5.2a = 0x0f (Power Management Control 5)
   0x03 LVDS Channel 1 Pad Control: 0x03
   0x0c LVDS Channel 2 Pad Control: 0x0c
   0x40 Spread Spectrum Type FIFO: 0x00
   3c5.2b

Re: [Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop

2017-03-14 Thread Xavier Bachelot 
On 14/03/2017 23:24, Xavier Bachelot wrote:
> Hi Kevin,
> 
> On 14/03/2017 22:33, Kevin Brace wrote:
>> Hi Xavier,
>>
>> Okay, at least some progress.
>> I was guessing that LVDS1 was still at IGA1, so switching to IGA2 will 
>> correct the problem, but I guess there were still some missing pieces.
>> Based on what you reported, I wrote a patch that should now correctly 
>> initialize LVDS1 for VX855 and VX900 chipsets.
>> It appears that these only have one LVDS channel as opposed to CX700/VX700 
>> and VX800 chipsets which appear to have two LVDS channels, to which one of 
>> them can be used as DVI.
>> I hope the patch works.
>>
> Thanks for the patch. It may or may not work, I can't tell, as both LVDS
> channels are powered down and thus the screen is black.
> I've attached the X log and regs dump.
> 
I guess that explains :

via_fp.c: In function ‘via_lvds_mode_set’:
via_fp.c:1300:13: warning: implicit declaration of function
‘viaLVDS1SetDithering’ [-Wimplicit-function-declaration]
 viaLVDS1SetDithering(pScrn, Panel->useDithering ? TRUE :
FALSE);
 ^~~~
via_fp.c:1303:13: warning: implicit declaration of function
‘viaLVDS1SetOutputFormat’ [-Wimplicit-function-declaration]
 viaLVDS1SetOutputFormat(pScrn, 0x01);
 ^~~

Xavier
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

Re: [Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop

2017-03-14 Thread Xavier Bachelot 
Hi Kevin,

On 14/03/2017 22:33, Kevin Brace wrote:
> Hi Xavier,
> 
> Okay, at least some progress.
> I was guessing that LVDS1 was still at IGA1, so switching to IGA2 will 
> correct the problem, but I guess there were still some missing pieces.
> Based on what you reported, I wrote a patch that should now correctly 
> initialize LVDS1 for VX855 and VX900 chipsets.
> It appears that these only have one LVDS channel as opposed to CX700/VX700 
> and VX800 chipsets which appear to have two LVDS channels, to which one of 
> them can be used as DVI.
> I hope the patch works.
> 
Thanks for the patch. It may or may not work, I can't tell, as both LVDS
channels are powered down and thus the screen is black.
I've attached the X log and regs dump.

btw, I don't know if you're used to irc but I'm on #openchrome on
freenode. Might be easier to debug this.

Regards,
Xavier
via-chrome-tool (C) 2009 by VIA Technologies, Inc.
This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY

Sequencer register dump (IO Port address: 0x3c4): 
   3c5.00 = 0x03 (Reset)
   3c5.01 = 0x01 (Clocking Mode)
   3c5.02 = 0x0f (Map Mask)
   3c5.03 = 0x00 (Character Map Select)
   3c5.04 = 0x0e (Memory Mode)
   3c5.10 = 0x01 (Extended Register Unlock)
   3c5.11 = 0x78 (Configuration 0)
   3c5.12 = 0x00 (Configuration 1)
   3c5.13 = 0x00 (Configuration 2 (DVP1 strapping))
   3c5.14 = 0x00 (Frame Buffer Size Control)
   3c5.15 = 0x22 (Display Mode Control)
   3c5.16 = 0x0c (Display FIFO Threshold Control)
   3c5.17 = 0x1f (Display FIFO Control)
   3c5.18 = 0x70 (Display Arbiter Control 0)
   3c5.19 = 0x7f (Power Management)
   0x01 CPU Interface Clock Control: 0x01
   0x02 Display Interface Clock Control: 0x02
   0x04 MC Interface Clock Control: 0x04
   0x08 Typical Arbiter Interface Clock Control: 0x08
   0x10 AGP Interface Clock Control: 0x10
   0x20 P-Arbiter Interface Clock Control: 0x20
   0x40 MIU/AGP Interface Clock Control: 0x40
   3c5.1a = 0x88 (PCI Bus Control)
   0x01 LUT Shadow Access: 0x00
   0x04 PCI Burst Write Wait State Select (0: 0 Wait state, 1: 1 Wait 
state): 0x00
   0x08 Extended Mode Memory Access Enable (0: Disable, 1: Enable): 0x08
   0x40 Software Reset (0: Default value, 1: Reset): 0x00
   0x80 Read Cache Enable (0: Disable, 1: Enable): 0x80
   3c5.1b = 0xf0 (Power Management Control 0)
   0x01 Primary Display's LUT Off: 0x00
   0x18 Primary Display Engine VCK Gating: 0x10
   0x60 Secondary Display Engine LCK Gating: 0x60
   3c5.1c = 0x54 (Horizontal Display Fetch Count Data)
   3c5.1d = 0x00 (Horizontal Display Fetch Count Control)
   3c5.1e = 0x01 (Power Management Control)
   0x01 ROC ECK: 0x01
   0x02 Replace ECK by MCK: 0x00
   0x08 Spread Spectrum: 0x00
   0x30 DVP1 Power Control: 0x00
   0xc0 VCP Power Control: 0x00
   3c5.20 = 0x00 (Typical Arbiter Control 0)
   3c5.21 = 0x18 (Typical Arbiter Control 1)
   3c5.22 = 0x14 (Display Arbiter Control 1)
   3c5.26 = 0x3d (IIC Serial Port Control 0)
   3c5.2a = 0x00 (Power Management Control 5)
   0x03 LVDS Channel 1 Pad Control: 0x00
   0x0c LVDS Channel 2 Pad Control: 0x00
   0x40 Spread Spectrum Type FIFO: 0x00
   3c5.2b = 0x01 (LVDS Interrupt Control)
   0x01 MSI Pending IRQ Re-trigger: 0x01
   0x02 CRT Hot Plug Detect Enable: 0x00
   0x04 CRT Sense IRQ status: 0x00
   0x08 CRT Sense IRQ enable: 0x00
   0x10 LVDS Sense IRQ status: 0x00
   0x20 LVDS Sense IRQ enable: 0x00
   3c5.2c = 0xdc (General Purpose I/O Port)
   3c5.2d = 0x3f (Power Management Control 1)
   0x03 ECK Pll Power Control: 0x03
   0x0c LCK PLL Power Control: 0x0c
   0x30 VCK PLL Power Control: 0x30
   0xc0 E3_ECK_N Selection: 0x00
   3c5.2e = 0xfb (Power Management Control 2)
   0x03 Video Playback Engine V3/V4 Gated Clock VCK: 0x03
   0x0c PCI Master / DMA Gated Clock ECK/CPUCK: 0x08
   0x30 Video Processor Gated Clock ECK: 0x30
   0xc0 Capturer Gated Clock ECK: 0xc0
   3c5.31 = 0x3d (IIC Serial Port Control 1)
   3c5.35 = 0x5b (Subsystem Vendor ID Low)
   3c5.36 = 0x10 (Subsystem Vendor ID High)
   3c5.37 = 0xfd (Subsystem ID Low)
   3c5.38 = 0x0c (Subsystem ID High)
   3c5.39 = 0x40 (BIOS Reserved Register 0)
   3c5.3a = 0x00 (BIOS Reserved Register 1)
   3c5.3b = 0x03 (PCI Revision ID Back Door)
   3c5.3c = 0x1d (Miscellaneous)
   0x01 AGP Bus Pack Door AGP3 Enable: 0x01
   0x02 Switch 3 PLLs to Prime Output: 0x00
   0x04 LCDCK PLL Locked Detect: 0x04
   0x08 VCK PLL Locked Detect: 0x08
   0x10 ECL PLL Locked Detect: 0x10
   0x60 PLL Frequency Division Select for Testing: 0x00
   3c5.3d = 0x0c (General Purpose I/O Port)
   3c5.3e = 0x00 (Miscellaneous Register for AGP Mux)
   3c5.3f = 0xff (Power Management Control 2)
   0x03 Video Clock Control (Gated ECK): 0x03
   0x0c 2D Clock Control (Gated ECK/CPUCK): 0x0c
   0x30 3D Clock Control (Gated ECK): 0x30
   0xc0 CR Clock Control (Gated ECK): 0xc0
   3c5.40 = 0x08

Re: [Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop

2017-03-14 Thread Xavier Bachelot 
Hi Kevin,

On 14/03/2017 04:42, Kevin Brace wrote:
> The register dump was helpful, and I think the cause of the FP not working is 
> due to LVDS1 (The VIA datasheet calls it LVDS Channel 0 sometimes, but I will 
> call it LVDS Channel 1. Accordingly, LVDS2 will be called LVDS Channel 2.) 
> sending IGA1 display stream, not IGA2.
> When the computer boots, it probably sets LVDS1 display stream source to 
> IGA1, and the register dump indicates this.
> If you manually switch the LVDS1 to IGA2, that should solve the bug.
> 
> $ cd tools
> $ sudo ./via_regs_dump -r 3d5.99
> 
> The screen according to your Version 0.6 + your panel index fix patch 
> returned 0x01.
> Now, write 0x11 to 3X5.99
> 
> $ sudo ./via_regs_dump -w 3d5.99 11
> 
> Bit 4 of 3X5.99 determines the display source.
> 0 for IGA1 and 1 for IGA2.
> I hope this experiment will get the screen back.
> It appears that the LCDCK PLL is set correctly, so hopefully this fix will 
> work.

That helps a bit, but does not fully fix the problem. A very distorted
image of what should be displayed is now showing in the upper half or
third of the FP. The remaining of the screen seems like uninitialized
memory.

Btw, via_regs_dump gets installed into /usr/sbin and also I'm here for
long enough to know how to build the driver and use the regs dumper, no
need to go into too much details. Actually, I did import the regs dumper
into the openchrome tree and even fixed a couple things in it.
For the record, the Epia M10K CLE266-based board that brought me to
Unichrome then Openchrome in 2004 just died, and I'm maintaining a
package for the driver for Fedora, unofficially then officially, since I
bought it. I still have a couple others VIA boards to play with (KM400A,
CN400, CN700, CX700, VX800, VX855 and VX900 based, some in a bad shape
though) possibly including another Epia M, I just need to find and
rescue it from a dusty shelf somewhere.

Regards,
Xavier
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

Re: [Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop

2017-03-13 Thread Xavier Bachelot 
Hi Kevin,

On 13/03/2017 23:56, Kevin Brace wrote:
> Regarding the first fix, I can consider taking it, but not really for
> the second fix. I think the problem here is that OpenChrome code
> currently lacks the proper initialization of certain unknown
> registers related to FP that VGA BIOS is setting correctly for IGA1,
> but not IGA2. After numerous experiments with OpenChrome DDX and the
> still in development OpenChrome DRM with KMS support, it appears that
> VGA BIOS initializes IGA1 for FP use coming out when the computer
> boots whatever OS, but due to certain registers not being set
> correctly by OpenChrome, it is the likely cause of why it does not
> work properly for IGA2 on VX900 chipset. Unfortunately, I do not own
> a laptop with VX900 chipset, although I do have two desktop models
> with VX900 chipset (ZOTAC ZBOX nano VD01 and ECS VX900-I mainboard). 
> None of them support flat panels (VX900-I has LVDS connector traces,
> but the connector is not populated) The solution to this bug I think
> will be to figure out which unknown register needs to be turned on in
> order for IGA2 to work correctly with a FP, not reversing the
> commit. I do not know the particular laptop model you are using, but
> assuming that the laptop in question comes with a VGA connector, you
> may want to use that when doing the debugging. You will like to do a
> dump of the registers to see what is going on.

Agreed, better a real fix than a revert, but that's what I came up with
after bisecting the issue. Oh, and no need for VGA, ssh is much easier.

So here are 2 registers dumps, one with plain 0.5.126, another with
0.6.0 plus only the panel resolution table fix in order to reduce the
differences.

Regards,
Xavier



via-chrome-tool (C) 2009 by VIA Technologies, Inc.
This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY

Sequencer register dump (IO Port address: 0x3c4): 
   3c5.00 = 0x00 (Reset)
   3c5.01 = 0x01 (Clocking Mode)
   3c5.02 = 0x0f (Map Mask)
   3c5.03 = 0x00 (Character Map Select)
   3c5.04 = 0x0e (Memory Mode)
   3c5.10 = 0x01 (Extended Register Unlock)
   3c5.11 = 0x78 (Configuration 0)
   3c5.12 = 0x00 (Configuration 1)
   3c5.13 = 0x00 (Configuration 2 (DVP1 strapping))
   3c5.14 = 0x00 (Frame Buffer Size Control)
   3c5.15 = 0xbe (Display Mode Control)
   3c5.16 = 0x90 (Display FIFO Threshold Control)
   3c5.17 = 0xc7 (Display FIFO Control)
   3c5.18 = 0x90 (Display Arbiter Control 0)
   3c5.19 = 0x7f (Power Management)
   0x01 CPU Interface Clock Control: 0x01
   0x02 Display Interface Clock Control: 0x02
   0x04 MC Interface Clock Control: 0x04
   0x08 Typical Arbiter Interface Clock Control: 0x08
   0x10 AGP Interface Clock Control: 0x10
   0x20 P-Arbiter Interface Clock Control: 0x20
   0x40 MIU/AGP Interface Clock Control: 0x40
   3c5.1a = 0x88 (PCI Bus Control)
   0x01 LUT Shadow Access: 0x00
   0x04 PCI Burst Write Wait State Select (0: 0 Wait state, 1: 1 Wait 
state): 0x00
   0x08 Extended Mode Memory Access Enable (0: Disable, 1: Enable): 0x08
   0x40 Software Reset (0: Default value, 1: Reset): 0x00
   0x80 Read Cache Enable (0: Disable, 1: Enable): 0x80
   3c5.1b = 0xf2 (Power Management Control 0)
   0x01 Primary Display's LUT Off: 0x00
   0x18 Primary Display Engine VCK Gating: 0x10
   0x60 Secondary Display Engine LCK Gating: 0x60
   3c5.1c = 0x56 (Horizontal Display Fetch Count Data)
   3c5.1d = 0x01 (Horizontal Display Fetch Count Control)
   3c5.1e = 0xf5 (Power Management Control)
   0x01 ROC ECK: 0x01
   0x02 Replace ECK by MCK: 0x00
   0x08 Spread Spectrum: 0x00
   0x30 DVP1 Power Control: 0x30
   0xc0 VCP Power Control: 0xc0
   3c5.20 = 0x00 (Typical Arbiter Control 0)
   3c5.21 = 0x18 (Typical Arbiter Control 1)
   3c5.22 = 0x28 (Display Arbiter Control 1)
   3c5.26 = 0x3d (IIC Serial Port Control 0)
   3c5.2a = 0x3f (Power Management Control 5)
   0x03 LVDS Channel 1 Pad Control: 0x03
   0x0c LVDS Channel 2 Pad Control: 0x0c
   0x40 Spread Spectrum Type FIFO: 0x00
   3c5.2b = 0x00 (LVDS Interrupt Control)
   0x01 MSI Pending IRQ Re-trigger: 0x00
   0x02 CRT Hot Plug Detect Enable: 0x00
   0x04 CRT Sense IRQ status: 0x00
   0x08 CRT Sense IRQ enable: 0x00
   0x10 LVDS Sense IRQ status: 0x00
   0x20 LVDS Sense IRQ enable: 0x00
   3c5.2c = 0xdc (General Purpose I/O Port)
   3c5.2d = 0x3f (Power Management Control 1)
   0x03 ECK Pll Power Control: 0x03
   0x0c LCK PLL Power Control: 0x0c
   0x30 VCK PLL Power Control: 0x30
   0xc0 E3_ECK_N Selection: 0x00
   3c5.2e = 0xfb (Power Management Control 2)
   0x03 Video Playback Engine V3/V4 Gated Clock VCK: 0x03
   0x0c PCI Master / DMA Gated Clock ECK/CPUCK: 0x08
   0x30 Video Processor Gated Clock ECK: 0x30
   0xc0 Capturer Gated Clock ECK: 0xc0
   3c5.31 = 0x3d (IIC Serial Port Control 1)
   3c5.35 = 0x5b (Subsystem Vendor ID Low)
   3c5.36 = 0x10 (Subsystem Vendor ID High)
   3c5.37 =

[Openchrome-devel] openchrome 0.6.0 regressions on VX900 laptop

2017-03-10 Thread Xavier Bachelot 
Hi,

I have a VX900 laptop that got broken twice between openchrome 0.5.0 and
0.6.0.

First breakage comes from the update of the panel resolution table with
the table from viafb. 0xA got changed from 1368x768 to 1024x768. I'm not
sure why the viafb table was assumed to be better than openchrome table,
but at least in this case, it proved to be wrong.

Faulty commit : d90a71c7146470162cb2bd1f76f9c5cfcec09101
Fix : attached patch.

Second breakage is unconditionally setting the flat panel to IGA2 for
the VX900. The VX900 is the only chipset which was allowed to be on
either IGA1 or IGA2, all older chipsets had the FP already fixed to
IGA2. For whatever reason, this doesn't work for this laptop, which then
only displays a garbled screen.

Faulty commit : 6b66a9ec3c0c3caf75e804f0abe19871df014c4b
Fix : revert the commit.

Happy to provide more testing or info if needed.

Regards,
Xavier

>From 45578f76437a68a69cfa256600a5785f835c83be Mon Sep 17 00:00:00 2001
From: Xavier Bachelot <xav...@bachelot.org>
Date: Sat, 11 Mar 2017 00:01:34 +0100
Subject: [PATCH] Fix panel resolution 0xA

---
 src/via_fp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/via_fp.c b/src/via_fp.c
index 798180f..b311f71 100644
--- a/src/via_fp.c
+++ b/src/via_fp.c
@@ -63,7 +63,7 @@ static ViaPanelModeRec ViaPanelNativeModes[] = {
 {1280,  800, FALSE,  TRUE},
 { 800,  480, FALSE,  TRUE},
 {1024,  768,  TRUE,  TRUE},
-{1024,  768, FALSE, FALSE},
+{1368,  768, FALSE, FALSE},
 {1024,  768,  TRUE, FALSE},
 {1280,  768, FALSE, FALSE},
 {1280, 1024,  TRUE, FALSE},
-- 
2.7.4

___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

Re: [Openchrome-devel] Status update on OpenChrome Version 0.6

2016-08-11 Thread Xavier Bachelot 

Hi Kevin,

On 11/08/2016 00:28, Kevin Brace wrote:


I do not really think I can fix any more bugs for Version 0.6, so I may tackle 
some of them for Version 0.7.


What about the build warnings fixes, at least the ones I have patches 
for ? See my other mail, it's all available from my git repo at fdo.


Regards,
Xavier

___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

Re: [Openchrome-devel] [PATCH] Treat all build warnings as errors

2016-08-11 Thread Xavier Bachelot 

Hi,

On 05/08/2016 17:09, Xavier Bachelot wrote:

On 05/08/2016 04:40, Bartosz wrote:

Also there will be a lot of warnings which will need to be resolved.
Fortunately fixing warnings will be a good task for novice developer.

What do you think about enabling "-Wall"?

Best Regards
Bartosz



Hi,

Enabling -Wall is probably a good idea, but we need to first fix all the
warnings then enable it. If we do it the other way, we'll be stuck with
build failures until all the warnings are fixed.
We probably want to also change the CFLAGS for the xvmc and tools
subdirs Makefiles.

Enabling -Wall now is not a problem indeed, -Werror is. Sorry for the 
bad wording, I was confused after sending the -Werror patch.



I suggest we use https://bugs.freedesktop.org/show_bug.cgi?id=96399 to
track this issue. I already attached some patches there.

Rather than attaching patches to the above bug, I pushed my changes to 
my fdo tree in the fix_warnings branch. The patches I posted to the 
mailing list a few days ago were white-space damaged by my mailer anyway.


git://people.freedesktop.org/~xavierb/xf86-video-openchrome fix_warnings

I choose to first enable -Wall, to make all the warning visible, then 
start to clean them.
-Werror can either be added when all warning are cleared, or can be 
added now together with a couple of -Wno-something.
I'd rather wait before enabling -Werror, as there are still a sizable 
number of warnings in the current code and adding -Wno-something would 
hide what -Wall unhide.


Please review and apply.

Indeed, feel free to send more patches or attach them to the bug, I can 
add them to my tree or Kevin can apply them to master directly.


Regards,
Xavier
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [PATCH 9/9] Fix format warnings

2016-08-05 Thread Xavier Bachelot 
Signed-off-by: Xavier Bachelot <xav...@bachelot.org>
---
 src/via_display.c | 8 
 src/via_ums.c | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/via_display.c b/src/via_display.c
index e772c7c..9076de8 100644
--- a/src/via_display.c
+++ b/src/via_display.c
@@ -830,11 +830,11 @@ viaIGA1SetFBStartingAddress(xf86CrtcPtr crtc, int
x, int y)
  Base = (y * pScrn->displayWidth + x) * (pScrn->bitsPerPixel / 8);
 DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_INFO,
-"Base Address: 0x%lx\n",
+"Base Address: 0x%x\n",
 Base));
 Base = (Base + drmmode->front_bo->offset) >> 1;
 xf86DrvMsg(pScrn->scrnIndex, X_INFO,
-"DRI Base Address: 0x%lx\n",
+"DRI Base Address: 0x%x\n",
 Base);
  hwp->writeCrtc(hwp, 0x0D, Base & 0xFF);
@@ -2071,11 +2071,11 @@ viaIGA2SetFBStartingAddress(xf86CrtcPtr crtc,
int x, int y)
  Base = (y * pScrn->displayWidth + x) * (pScrn->bitsPerPixel / 8);
 DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_INFO,
-"Base Address: 0x%lx\n",
+"Base Address: 0x%x\n",
 Base));
 Base = (Base + drmmode->front_bo->offset) >> 3;
 xf86DrvMsg(pScrn->scrnIndex, X_INFO,
-"DRI Base Address: 0x%lx\n",
+"DRI Base Address: 0x%x\n",
 Base);
  tmp = hwp->readCrtc(hwp, 0x62) & 0x01;
diff --git a/src/via_ums.c b/src/via_ums.c
index 92b2cb5..e6e203d 100644
--- a/src/via_ums.c
+++ b/src/via_ums.c
@@ -186,7 +186,7 @@ viaMapMMIO(ScrnInfoPtr pScrn)
  xf86DrvMsg(pScrn->scrnIndex, X_PROBED,
"Mapping the frame buffer at address 0x%lX with "
-   "size %u KB.\n",
+   "size %lu KB.\n",
pVia->FrameBufferBase, pVia->videoRambytes / 1024);
  #ifdef HAVE_PCIACCESS
-- 
2.7.4

___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [PATCH 8/9] Fix /* within comment warning

2016-08-05 Thread Xavier Bachelot 
Signed-off-by: Xavier Bachelot <xav...@bachelot.org>
---
 src/via_lvds.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/via_lvds.c b/src/via_lvds.c
index c78390c..bd4a3c9 100644
--- a/src/via_lvds.c
+++ b/src/via_lvds.c
@@ -113,7 +113,7 @@ viaLVDS1SetDisplaySource(ScrnInfoPtr pScrn, CARD8
displaySource)
 "Entered viaLVDS1SetDisplaySource.\n"));
  /* Set LVDS1 integrated LVDS transmitter display output source.
-/* 3X5.99[4] - LVDS Channel 1 Data Source Selection
+ * 3X5.99[4] - LVDS Channel 1 Data Source Selection
  * 0: Primary Display
  * 1: Secondary Display */
 ViaCrtcMask(hwp, 0x99, temp << 4, 0x10);
@@ -140,7 +140,7 @@ viaLVDS2SetDisplaySource(ScrnInfoPtr pScrn, CARD8
displaySource)
 "Entered viaLVDS2SetDisplaySource.\n"));
  /* Set LVDS2 integrated LVDS transmitter display output source.
-/* 3X5.97[4] - LVDS Channel 2 Data Source Selection
+ * 3X5.97[4] - LVDS Channel 2 Data Source Selection
  * 0: Primary Display
  * 1: Secondary Display */
 ViaCrtcMask(hwp, 0x97, temp << 4, 0x10);
-- 
2.7.4


___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [PATCH 5/9] Fix unused-variable warning in via_vt1632.c.

2016-08-05 Thread Xavier Bachelot 
Signed-off-by: Xavier Bachelot <xav...@bachelot.org>
---
 src/via_vt1632.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/via_vt1632.c b/src/via_vt1632.c
index 7e669cf..45e57ca 100644
--- a/src/via_vt1632.c
+++ b/src/via_vt1632.c
@@ -204,7 +204,6 @@ Bool
 viaVT1632Init(ScrnInfoPtr pScrn, I2CBusPtr pI2CBus)
 {
 xf86OutputPtr output;
-VIAPtr pVia = VIAPTR(pScrn);
 ViaVT1632Ptr pVIAVT1632Rec = NULL;
 I2CDevPtr pI2CDevice = NULL;
 I2CSlaveAddr i2cAddr = 0x10;
-- 
2.7.4


___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [PATCH 4/9] Fix unused-variable warnings in via_tmds.c.

2016-08-05 Thread Xavier Bachelot 
Signed-off-by: Xavier Bachelot <xav...@bachelot.org>
---
 src/via_tmds.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/src/via_tmds.c b/src/via_tmds.c
index a6b665e..55f43c5 100644
--- a/src/via_tmds.c
+++ b/src/via_tmds.c
@@ -246,8 +246,6 @@ via_dvi_get_property(xf86OutputPtr output, Atom
property)
 static void
 via_dvi_dpms(xf86OutputPtr output, int mode)
 {
-ScrnInfoPtr pScrn = output->scrn;
-
 switch (mode) {
 case DPMSModeOn:
 via_vt1632_power(output, TRUE);
@@ -302,7 +300,6 @@ via_dvi_mode_set(xf86OutputPtr output,
DisplayModePtr mode,
  DisplayModePtr adjusted_mode)
 {
 ScrnInfoPtr pScrn = output->scrn;
-vgaHWPtr hwp = VGAHWPTR(pScrn);
  via_vt1632_mode_set(output, mode, adjusted_mode);
 }
@@ -312,7 +309,6 @@ via_dvi_detect(xf86OutputPtr output)
 {
 xf86OutputStatus status = XF86OutputStatusDisconnected;
 ScrnInfoPtr pScrn = output->scrn;
-VIAPtr pVia = VIAPTR(pScrn);
 ViaVT1632Ptr Private = output->driver_private;
 xf86MonPtr mon;
 @@ -518,7 +514,6 @@ via_tmds_detect(xf86OutputPtr output)
 xf86OutputStatus status = XF86OutputStatusDisconnected;
 ScrnInfoPtr pScrn = output->scrn;
 VIAPtr pVia = VIAPTR(pScrn);
-VIATMDSRecPtr pVIATMDSRec = output->driver_private;
  DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_INFO,
 "Entered via_tmds_detect.\n"));
@@ -644,7 +639,6 @@ viaTMDSInit(ScrnInfoPtr pScrn)
 {
 xf86OutputPtr output;
 vgaHWPtr hwp = VGAHWPTR(pScrn);
-VIAPtr pVia = VIAPTR(pScrn);
 VIATMDSRecPtr pVIATMDSRec = NULL;
 CARD8 sr13, sr5a, cr3e;
 Bool status = FALSE;
@@ -729,11 +723,6 @@ void
 via_dvi_init(ScrnInfoPtr pScrn)
 {
 VIAPtr pVia = VIAPTR(pScrn);
-xf86OutputPtr output = NULL;
-ViaVT1632Ptr private_data = NULL;
-I2CBusPtr pBus = NULL;
-I2CDevPtr pDev = NULL;
-I2CSlaveAddr addr = 0x10;
  DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_INFO,
 "Entered via_dvi_init.\n"));
-- 
2.7.4


___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

Re: [Openchrome-devel] [PATCH] Treat all build warnings as errors

2016-08-05 Thread Xavier Bachelot 
On 05/08/2016 04:40, Bartosz wrote:
> Hi
> In attachment you have all warnings which was produced by using "-Wall" 
> 
> We could always silent some types of warnings if we think it is not needed.
>  For example to silent all [-Wunused-variable] warnings:
> 
>  -Werror -Wall -Wno-unused-variable
> 
> Best Regards
> Bartosz
> 
> 2016-08-05 4:28 GMT+02:00 Bartosz >:
> 
> Thanks Xavier.
> 
> It will be great to also enable "-Wall" parameter.
> http://www.rapidtables.com/code/linux/gcc/gcc-wall.htm
> 
> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
> 
> 
> -Wall turns on the following warning flags:
> 
>   -Waddress   
>   -Warray-bounds=1 (only with -O2)  
>   -Wbool-compare  
>   -Wc++11-compat  -Wc++14-compat
>   -Wchar-subscripts  
>   -Wcomment  
>   -Wduplicate-decl-specifier (C and Objective-C only) 
>   -Wenum-compare (in C/ObjC; this is on by default in C++) 
>   -Wformat   
>   -Wimplicit (C and Objective-C only) 
>   -Wimplicit-int (C and Objective-C only) 
>   -Wimplicit-function-declaration (C and Objective-C only) 
>   -Winit-self (only for C++) 
>   -Wlogical-not-parentheses
>   -Wmain (only for C/ObjC and unless -ffreestanding)  
>   -Wmaybe-uninitialized 
>   -Wmemset-elt-size 
>   -Wmemset-transposed-args 
>   -Wmisleading-indentation (only for C/C++) 
>   -Wmissing-braces (only for C/ObjC) 
>   -Wnarrowing (only for C++)  
>   -Wnonnull  
>   -Wnonnull-compare  
>   -Wopenmp-simd 
>   -Wparentheses  
>   -Wpointer-sign  
>   -Wreorder   
>   -Wreturn-type  
>   -Wsequence-point  
>   -Wsign-compare (only in C++)  
>   -Wsizeof-pointer-memaccess 
>   -Wstrict-aliasing  
>   -Wstrict-overflow=1  
>   -Wswitch  
>   -Wtautological-compare  
>   -Wtrigraphs  
>   -Wuninitialized  
>   -Wunknown-pragmas  
>   -Wunused-function  
>   -Wunused-label 
>   -Wunused-value 
>   -Wunused-variable  
>   -Wvolatile-register-var 
> 
> 
> It will keep code cleaner, and will give you a message if something
> suspicious will happen.
> 
> Also there will be a lot of warnings which will need to be resolved.
> Fortunately fixing warnings will be a good task for novice developer.
> 
> What do you think about enabling "-Wall"?
> 
> Best Regards
> Bartosz
> 
>
Hi,

Enabling -Wall is probably a good idea, but we need to first fix all the
warnings then enable it. If we do it the other way, we'll be stuck with
build failures until all the warnings are fixed.
We probably want to also change the CFLAGS for the xvmc and tools
subdirs Makefiles.

I suggest we use https://bugs.freedesktop.org/show_bug.cgi?id=96399 to
track this issue. I already attached some patches there.

Regards,
Xavier


___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [PATCH] Treat all build warnings as errors

2016-08-04 Thread Xavier Bachelot 

Signed-off-by: Xavier Bachelot <xav...@bachelot.org>
---
I don't know my way through autotools very well, so not sure this is the 
best way, but it works...


 src/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index 82224d4..6ff7e31 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -29,7 +29,7 @@ SUBDIRS = xvmc
 BUILT_SOURCES = version.h
 EXTRA_DIST = version.h
 CONFIG_CLEAN_FILES= version.h
-AM_CFLAGS = @XORG_CFLAGS@ @LIBUDEV_CFLAGS@ @DRI_CFLAGS@
+AM_CFLAGS = @XORG_CFLAGS@ @LIBUDEV_CFLAGS@ @DRI_CFLAGS@ -Werror
 openchrome_drv_la_LTLIBRARIES = openchrome_drv.la
 openchrome_drv_la_LDFLAGS = -module -avoid-version @LIBUDEV_LIBS@
 openchrome_drv_ladir = @moduledir@/drivers
--
2.7.4

___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [PATCH] Properly use bitwise operators in viaProbePinStrapping

2016-06-13 Thread Xavier Bachelot 
Signed-off-by: Xavier Bachelot <xav...@bachelot.org>
---
 src/via_outputs.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/via_outputs.c b/src/via_outputs.c
index 7e21e8c..04b8a83 100644
--- a/src/via_outputs.c
+++ b/src/via_outputs.c
@@ -1045,7 +1045,7 @@ viaProbePinStrapping(ScrnInfoPtr pScrn)
 /* 3C5.12[4] - FPD17 pin strapping
  * 0: TMDS transmitter (DVI) / capture device
  * 1: Flat panel */
-if (sr12 && 0x10) {
+if (sr12 & 0x10) {
 xf86DrvMsg(pScrn->scrnIndex, X_INFO,
 "A flat panel is connected to "
 "flat panel interface.\n");
@@ -1065,7 +1065,7 @@ viaProbePinStrapping(ScrnInfoPtr pScrn)
 /* 3C5.12[5] - FPD18 pin strapping
  * 0: TMDS transmitter (DVI)
  * 1: TV encoder */
-if (sr12 && 0x20) {
+if (sr12 & 0x20) {
 xf86DrvMsg(pScrn->scrnIndex, X_INFO,
 "A TMDS transmitter (DVI) is connected to "
 "DVI port.\n");
@@ -1079,11 +1079,11 @@ viaProbePinStrapping(ScrnInfoPtr pScrn)
  *   01: NTSC
  *   10: PAL-N
  *   11: PAL-NC */
-if (sr13 && 0x04) {
+if (sr13 & 0x04) {
 xf86DrvMsg(pScrn->scrnIndex, X_INFO,
 "NTSC for the TV encoder.\n");
 } else {
-if (!(sr13 && 0x08)) {
+if (!(sr13 & 0x08)) {
 xf86DrvMsg(pScrn->scrnIndex, X_INFO,
 "PAL for the TV encoder.\n");
 } else {
@@ -1112,12 +1112,12 @@ viaProbePinStrapping(ScrnInfoPtr pScrn)
  *DVI or TV out use
  * 1: Enable DVP0 (Digital Video Port 0) for
  *DVI or TV out use */
-if (sr12 && 0x40) {
+if (sr12 & 0x40) {
  /* 3C5.12[5] - DVP0D5 pin strapping
  * 0: TMDS transmitter (DVI)
  * 1: TV encoder */
-if (sr12 && 0x20) {
+if (sr12 & 0x20) {
 xf86DrvMsg(pScrn->scrnIndex, X_INFO,
 "A TV encoder is detected on "
 "DVP0 (Digital Video Port 0).\n");
@@ -1133,7 +1133,7 @@ viaProbePinStrapping(ScrnInfoPtr pScrn)
  * 0: AGP pins are used for AGP
  * 1: AGP pins are used by FPDP
  * (Flat Panel Display Port) */
-if (sr13 && 0x08) {
+if (sr13 & 0x08) {
  /* 3C5.12[4] - DVP0D4 pin strapping
  * 0: Dual 12-bit FPDP (Flat Panel Display Port)
@@ -1159,7 +1159,7 @@ viaProbePinStrapping(ScrnInfoPtr pScrn)
  * 3C5.12[5] - DVP0D5 pin strapping
  * 0: TMDS transmitter (DVI)
  * 1: TV encoder */
-if ((!(sr12 && 0x40)) && (!(sr12 && 0x20))) {
+if ((!(sr12 & 0x40)) && (!(sr12 & 0x20))) {
 xf86DrvMsg(pScrn->scrnIndex, X_INFO,
 "A TV encoder is connected to "
 "FPDP (Flat Panel Display Port).\n");
@@ -1206,7 +1206,7 @@ viaProbePinStrapping(ScrnInfoPtr pScrn)
  *   01: DVI + LVDS2
  *   10: Dual LVDS Channel (High Resolution Panel)
  *   11: One DVI only (decrease the clock jitter) */
-switch (sr13 && 0xC0) {
+switch (sr13 & 0xC0) {
 case 0x00:
 xf86DrvMsg(pScrn->scrnIndex, X_INFO,
 "LVDS1 + LVDS2 detected.\n");
-- 
2.5.5

___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

Re: [Openchrome-devel] xf86-video-openchrome: src/via_display.c src/via_driver.c src/via_driver.h src/via_lvds.c src/via_outputs.c

2016-04-05 Thread Xavier Bachelot 
Hi Kevin,

On 05/04/2016 05:56, Kevin Brace wrote:
> Hi Xavier,
> 
>> Sent: Wednesday, March 30, 2016 at 1:31 AM From: "Xavier Bachelot"
>> <xav...@bachelot.org> To: openchrome-devel@lists.freedesktop.org,
>> "Kevin Brace" <kevinbr...@gmx.com> Subject: Re: [Openchrome-devel]
>> xf86-video-openchrome: src/via_display.c src/via_driver.c
>> src/via_driver.h src/via_lvds.c src/via_outputs.c
>> 
>> Hi Kevin,
>> 
>> On 18/03/2016 13:20, Kevin Brace wrote:
>>> src/via_display.c |   35 +-- src/via_driver.c  |   40 --- 
>>> src/via_driver.h  |1 src/via_lvds.c|  613
>>> +++--- 
>>> src/via_outputs.c |  128 --- 5 files changed, 98
>>> insertions(+), 719 deletions(-)
>>> 
>>> New commits: commit b48fb4176c96b04f5de8b2ee20f55af404ba0db7 
>>> Author: Kevin Brace <kevinbr...@gmx.com> Date:   Fri Mar 18
>>> 05:11:56 2016 -0700
>>> 
>>> Removal of legacy user mode setting
>>> 
>>> OpenChrome has had multiple ways to configure the display mode.
>>> This added unnecessary code maintenance burden on the developers.
>>> Hence, the legacy user mode setting is now discontinued.
>>> 
>>> Signed-off-by: Kevin Brace <kevinbr...@gmx.com>
>>> 
>> 
>> I believe this breaks my CLE266 + VGA. No time to really
>> investigate the issue yet, and I reverted to the commit just before
>> this one mostly out of a guess.
>> 
>> I'll properly bisect and post logs and registers dumps for both the
>>  working and non-working case shortly.
>> 
>> Regards, Xavier
>> 
> 
> If you have a specific situation of OpenChrome Version 0.4.0 not
> working, please file a bug report with http://bugs.freedesktop.org. I
> typically ask everyone seeking help to do this.
Will do. I just sent a note as soon as I observed the regression on my
setup and I know this is definitely not enough to debug the issue.
Meanwhile, I've confirmed this is the faulty commit.
Actually, I think I already stumbled on this very bug long time ago when
James rewrote some part of the code and that's why CLE266 was reverted
to legacy mode setting to avoid introducing a regression. Not sure why
we did not fully debug this, but there was so many moving parts at the
moment, we probably ran out of time then forgot about it to concentrate
on KMS.
I'm probably going to ship openchrome 0.4.0 on Fedora with a patch to
revert the legacy mode setting removal. Indeed, this is only a temporary
workaround, I don't want to maintain out of tree patches unless
absolutely necessary and will remove it asap.

> Just to be very clear, I will not fix any bugs that appear in
> versions older than Version 0.4.0, and certainly, I will not revive
> VBE and legacy mode setting (and "known device table"). I did make a
> few commits that fixed a problem I observed with CLE266 (EPIA-M) and
> VX800 (EPIA-M830) chipsets before the new release.
I don't particularly care about VBE, nor legacy mode setting. Less code,
less bug :-)
On the other hand, the known devices table might be a bit more
problematic for older laptops. It was used in the first place to allow
enabling otherwise undetectable LVDS panel. That being said, I
completely agree this is/was a maintenance burden, I've been trying to
keep it up to date for years, and I'm more than happy to see it go.
Hopefully the code you added is enough to handle such cases. This is
definitely something that people with the hardware need to test, and
that's not my case.

> Please note that I did test the code with 2 CLE266 chipset mainboards
> (EPIA-CL and EPIA-M). Both of them worked without issues, although
> both of them still suffer from a standby mode resume bug even today
> (This is disclosed in the newly rewritten README file that came with
> the new release.). I used Ubuntu 10.04 LTS for testing.
One cannot test every possible hardware and software setup, and bugs
will fall through the cracks. This did happen numerous time already and
will happen again :-)

> Although I probably should not get personal, I will need to let you
> know that I sent you 4 e-mails between October 2015 to December 2015
> regarding OpenChrome. It appears that you choose to ignore all of
> them. You are under no obligation to explain why you choose to do
> this to me, but personally, I think it is very unprofessional to
> completely ignore me this way. While I sent several e-mails to James
> Simmons around the same time, at least he has completely disappeared
> since January 2015 or so.
> 
Sorry about that, but please note I did not ignore you, I was unable to
answer and I did already explain why in a private mail to you and a
couple

Re: [Openchrome-devel] DRI1 to be removed from X server

2015-12-10 Thread Xavier Bachelot 

Hi Benno,

On 10/12/2015 11:15, Benno Schulenberg wrote:

Hi Xavier,

On Wed, Dec 9, 2015, at 15:20, Xavier Bachelot wrote:

FYI, It seems that DRI1 support might be removed from X server :
http://lists.x.org/archives/xorg-devel/2015-December/048182.html

This will be a big issue for openchrome and urges greatly the urgency of
moving to DRI2 at least.

Would it be an idea to make a 0.3.4 release sometime soon?
There hasn't been one in two and a half years.  There haven't
been many changes but... they might save someone's day.
This has been on my todo since March, last time I talked with James, but 
real life has been rather though with me lately, so I'm fighting to find 
both the time an energy to do it. I'll try and do a release before the 
end of the year.

Also, Kevin is proposing several patches.  Are you looking into
that?  Or are they too intrusive?
I've been quickly reading through them. I still have some comments I 
need to send but after a bit of shaping up, it should be good to go, 
given the various chipsets get a test run for possible regressions. I 
definitely need to dust of my VIA test farm.
Any help reviewing the patches would be greatly appreciated. I'll also 
try to get in touch with James to see what's he's up to these days.

It seems Mario is warming up too, our mails about DRI1 crossed yesterday.

Regards,
Xavier
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] DRI1 to be removed from X server

2015-12-09 Thread Xavier Bachelot 

Hi,

FYI, It seems that DRI1 support might be removed from X server :
http://lists.x.org/archives/xorg-devel/2015-December/048182.html

This will be a big issue for openchrome and urges greatly the urgency of 
moving to DRI2 at least.


I know there's not been much activity lately, but let's hope someone 
will take up this task rather sooner than later.


Regards,
Xavier
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] xf86-video-openchrome: 3 commits - src/via_id.c

2015-01-18 Thread Xavier Bachelot 
 src/via_id.c |   21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

New commits:
commit 98d43c48d100a02819397cf951ae8061f1f6124c
Author: Xavier Bachelot xav...@bachelot.org
Date:   Sat Jan 17 13:00:00 2015 +0100

Rewrap some lines below 80 chars

Signed-off-by: Xavier Bachelot xav...@bachelot.org
Acked-by: James Simmons jsimm...@infradead.org

diff --git a/src/via_id.c b/src/via_id.c
index cc6e746..ba28f9d 100644
--- a/src/via_id.c
+++ b/src/via_id.c
@@ -301,13 +301,16 @@ ViaCheckCardId(ScrnInfoPtr pScrn)
 if ((SUBVENDOR_ID(pVia-PciInfo) == VENDOR_ID(pVia-PciInfo)) 
 (SUBSYS_ID(pVia-PciInfo) == DEVICE_ID(pVia-PciInfo)))
 xf86DrvMsg(pScrn-scrnIndex, X_WARNING,
-   Manufacturer plainly copied main PCI IDs to subsystem/card 
IDs.\n);
+   Manufacturer plainly copied main PCI IDs to
+subsystem/card IDs.\n);
 
 for (Id = ViaCardId; Id-String; Id++) {
 if ((Id-Chip == pVia-Chipset) 
 (Id-Vendor == SUBVENDOR_ID(pVia-PciInfo)) 
 (Id-Device == SUBSYS_ID(pVia-PciInfo))) {
-xf86DrvMsg(pScrn-scrnIndex, X_PROBED, Detected %s. Card-Ids 
(%4X|%4X)\n, Id-String, SUBVENDOR_ID(pVia-PciInfo), 
SUBSYS_ID(pVia-PciInfo));
+xf86DrvMsg(pScrn-scrnIndex, X_PROBED,
+   Detected %s. Card-Ids (%4X|%4X)\n, Id-String,
+   SUBVENDOR_ID(pVia-PciInfo), SUBSYS_ID(pVia-PciInfo));
 pVia-ActiveDevice = Id-Outputs;
 pVia-Id = Id;
 return;
@@ -315,7 +318,9 @@ ViaCheckCardId(ScrnInfoPtr pScrn)
 }
 
 xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
-   Unknown Card-Ids (%4X|%4X|%4X), Chipset: %s; please report to 
openchrome-us...@lists.freedesktop.org\n,
-   DEVICE_ID(pVia-PciInfo), SUBVENDOR_ID(pVia-PciInfo), 
SUBSYS_ID(pVia-PciInfo), pScrn-chipset);
+   Unknown Card-Ids (%4X|%4X|%4X), Chipset: %s; please report to
+openchrome-us...@lists.freedesktop.org\n,
+   DEVICE_ID(pVia-PciInfo), SUBVENDOR_ID(pVia-PciInfo),
+   SUBSYS_ID(pVia-PciInfo), pScrn-chipset);
 pVia-Id = Id;
 }
commit dc485f2e0f432c2fe9d2e747259d999175dc834c
Author: Xavier Bachelot xav...@bachelot.org
Date:   Sat Jan 17 12:42:52 2015 +0100

Move CLE266 revision check to a place it will actually be run.

Signed-off-by: Xavier Bachelot xav...@bachelot.org
Acked-by: James Simmons jsimm...@infradead.org

diff --git a/src/via_id.c b/src/via_id.c
index 4071ffe..cc6e746 100644
--- a/src/via_id.c
+++ b/src/via_id.c
@@ -295,6 +295,9 @@ ViaCheckCardId(ScrnInfoPtr pScrn)
 struct ViaCardIdStruct *Id;
 VIAPtr pVia = VIAPTR(pScrn);
 
+if (pVia-Chipset == VIA_CLE266)
+ViaDoubleCheckCLE266Revision(pScrn);
+
 if ((SUBVENDOR_ID(pVia-PciInfo) == VENDOR_ID(pVia-PciInfo)) 
 (SUBSYS_ID(pVia-PciInfo) == DEVICE_ID(pVia-PciInfo)))
 xf86DrvMsg(pScrn-scrnIndex, X_WARNING,
@@ -315,7 +318,4 @@ ViaCheckCardId(ScrnInfoPtr pScrn)
Unknown Card-Ids (%4X|%4X|%4X), Chipset: %s; please report to 
openchrome-us...@lists.freedesktop.org\n,
DEVICE_ID(pVia-PciInfo), SUBVENDOR_ID(pVia-PciInfo), 
SUBSYS_ID(pVia-PciInfo), pScrn-chipset);
 pVia-Id = Id;
-
-if (pVia-Chipset == VIA_CLE266)
-ViaDoubleCheckCLE266Revision(pScrn);
 }
commit ecb1695ac2de1d840c036f64b5b71602e0f522a4
Author: Xavier Bachelot xav...@bachelot.org
Date:   Sat Jan 17 12:42:06 2015 +0100

Make sure pVia-Id is set even in case of an unknown board to prevent a 
segfault later

Signed-off-by: Xavier Bachelot xav...@bachelot.org
Acked-by: James Simmons jsimm...@infradead.org

diff --git a/src/via_id.c b/src/via_id.c
index a066819..4071ffe 100644
--- a/src/via_id.c
+++ b/src/via_id.c
@@ -314,7 +314,7 @@ ViaCheckCardId(ScrnInfoPtr pScrn)
 xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
Unknown Card-Ids (%4X|%4X|%4X), Chipset: %s; please report to 
openchrome-us...@lists.freedesktop.org\n,
DEVICE_ID(pVia-PciInfo), SUBVENDOR_ID(pVia-PciInfo), 
SUBSYS_ID(pVia-PciInfo), pScrn-chipset);
-pVia-Id = NULL;
+pVia-Id = Id;
 
 if (pVia-Chipset == VIA_CLE266)
 ViaDoubleCheckCLE266Revision(pScrn);
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [xf86-video-openchrome]X driver for VIA IGPs branch master updated. release_0_3_3-36-g98d43c4

2015-01-18 Thread Xavier Bachelot 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project X driver for VIA IGPs.

The branch, master has been updated
   via  98d43c48d100a02819397cf951ae8061f1f6124c (commit)
   via  dc485f2e0f432c2fe9d2e747259d999175dc834c (commit)
   via  ecb1695ac2de1d840c036f64b5b71602e0f522a4 (commit)
  from  33fcaa11daeb7ca156fcdadd969ca7f950ce8401 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 98d43c48d100a02819397cf951ae8061f1f6124c
Author: Xavier Bachelot xav...@bachelot.org
Date:   Sat Jan 17 13:00:00 2015 +0100

Rewrap some lines below 80 chars

Signed-off-by: Xavier Bachelot xav...@bachelot.org
Acked-by: James Simmons jsimm...@infradead.org

commit dc485f2e0f432c2fe9d2e747259d999175dc834c
Author: Xavier Bachelot xav...@bachelot.org
Date:   Sat Jan 17 12:42:52 2015 +0100

Move CLE266 revision check to a place it will actually be run.

Signed-off-by: Xavier Bachelot xav...@bachelot.org
Acked-by: James Simmons jsimm...@infradead.org

commit ecb1695ac2de1d840c036f64b5b71602e0f522a4
Author: Xavier Bachelot xav...@bachelot.org
Date:   Sat Jan 17 12:42:06 2015 +0100

Make sure pVia-Id is set even in case of an unknown board to prevent a 
segfault later

Signed-off-by: Xavier Bachelot xav...@bachelot.org
Acked-by: James Simmons jsimm...@infradead.org

---

Summary of changes:
 src/via_id.c |   21 +
 1 file changed, 13 insertions(+), 8 deletions(-)


hooks/post-receive
-- 
X driver for VIA IGPs
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] xf86-video-openchrome: src/via_outputs.c

2015-01-18 Thread Xavier Bachelot 
 src/via_outputs.c |  202 --
 1 file changed, 107 insertions(+), 95 deletions(-)

New commits:
commit 40dd677c721f4d1b1f7f29e7745fc81402abeb8b
Author: Xavier Bachelot xav...@bachelot.org
Date:   Sun Jan 18 21:18:50 2015 +0100

Cosmetic : Wrap lines and remove tabs indentation.

Signed-off-by: Xavier Bachelot xav...@bachelot.org

diff --git a/src/via_outputs.c b/src/via_outputs.c
index d488130..01554f7 100644
--- a/src/via_outputs.c
+++ b/src/via_outputs.c
@@ -124,7 +124,7 @@ ViaTVSetMode(xf86CrtcPtr crtc, DisplayModePtr mode)
 if (pBIOSInfo-TVModeCrtc)
 pBIOSInfo-TVModeCrtc(crtc, mode);
 
-   /* TV reset. */
+/* TV reset. */
 xf86I2CWriteByte(pBIOSInfo-TVI2CDev, 0x1D, 0x00);
 xf86I2CWriteByte(pBIOSInfo-TVI2CDev, 0x1D, 0x80);
 }
@@ -164,7 +164,7 @@ via_tv_create_resources(xf86OutputPtr output)
 #ifdef RANDR_12_INTERFACE
 static Bool
 via_tv_set_property(xf86OutputPtr output, Atom property,
-   RRPropertyValuePtr value)
+RRPropertyValuePtr value)
 {
 return TRUE;
 }
@@ -237,7 +237,7 @@ via_tv_mode_valid(xf86OutputPtr output, DisplayModePtr 
pMode)
 
 static Bool
 via_tv_mode_fixup(xf86OutputPtr output, DisplayModePtr mode,
-   DisplayModePtr adjusted_mode)
+  DisplayModePtr adjusted_mode)
 {
 return TRUE;
 }
@@ -259,7 +259,8 @@ ViaDisplayEnableDVO(ScrnInfoPtr pScrn, int port)
 {
 vgaHWPtr hwp = VGAHWPTR(pScrn);
 
-DEBUG(xf86DrvMsg(pScrn-scrnIndex, X_INFO, ViaDisplayEnableDVO, port: 
%d\n, port));
+DEBUG(xf86DrvMsg(pScrn-scrnIndex, X_INFO, ViaDisplayEnableDVO, port: 
%d\n,
+ port));
 switch (port) {
 case VIA_DI_PORT_DVP0:
 ViaSeqMask(hwp, 0x1E, 0xC0, 0xC0);
@@ -275,7 +276,8 @@ ViaDisplayDisableDVO(ScrnInfoPtr pScrn, int port)
 {
 vgaHWPtr hwp = VGAHWPTR(pScrn);
 
-DEBUG(xf86DrvMsg(pScrn-scrnIndex, X_INFO, ViaDisplayDisableDVO, port: 
%d\n, port));
+DEBUG(xf86DrvMsg(pScrn-scrnIndex, X_INFO, ViaDisplayDisableDVO, port: 
%d\n,
+ port));
 switch (port) {
 case VIA_DI_PORT_DVP0:
 ViaSeqMask(hwp, 0x1E, 0x00, 0xC0);
@@ -292,7 +294,8 @@ ViaDisplaySetStreamOnDVO(ScrnInfoPtr pScrn, int port, int 
iga)
 vgaHWPtr hwp = VGAHWPTR(pScrn);
 int regNum;
 
-DEBUG(xf86DrvMsg(pScrn-scrnIndex, X_INFO, ViaDisplaySetStreamOnDVO, 
port: %d\n, port));
+DEBUG(xf86DrvMsg(pScrn-scrnIndex, X_INFO, ViaDisplaySetStreamOnDVO, 
port: %d\n,
+ port));
 
 switch (port) {
 case VIA_DI_PORT_DVP0:
@@ -317,7 +320,7 @@ ViaDisplaySetStreamOnDVO(ScrnInfoPtr pScrn, int port, int 
iga)
 
 static void
 via_tv_mode_set(xf86OutputPtr output, DisplayModePtr mode,
-   DisplayModePtr adjusted_mode)
+DisplayModePtr adjusted_mode)
 {
 ScrnInfoPtr pScrn = output-scrn;
 VIAPtr pVia = VIAPTR(pScrn);
@@ -481,7 +484,8 @@ via_tv_init(ScrnInfoPtr pScrn)
 /* Allow tv output on both crtcs, set bit 0 and 1. */
 output-possible_crtcs = 0x3;
 } else {
-xf86DrvMsg(pScrn-scrnIndex, X_ERROR, via_tv_init: Failed to create 
output for TV-1.\n);
+xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
+   via_tv_init: Failed to create output for TV-1.\n);
 }
 
 pBIOSInfo-tv = output;
@@ -503,7 +507,7 @@ via_dp_create_resources(xf86OutputPtr output)
 #ifdef RANDR_12_INTERFACE
 static Bool
 via_dp_set_property(xf86OutputPtr output, Atom property,
-   RRPropertyValuePtr value)
+RRPropertyValuePtr value)
 {
 return TRUE;
 }
@@ -555,7 +559,7 @@ via_dp_mode_valid(xf86OutputPtr output, DisplayModePtr 
pMode)
 
 static Bool
 via_dp_mode_fixup(xf86OutputPtr output, DisplayModePtr mode,
-   DisplayModePtr adjusted_mode)
+  DisplayModePtr adjusted_mode)
 {
 return TRUE;
 }
@@ -572,7 +576,7 @@ via_dp_commit(xf86OutputPtr output)
 
 static void
 via_dp_mode_set(xf86OutputPtr output, DisplayModePtr mode,
-   DisplayModePtr adjusted_mode)
+DisplayModePtr adjusted_mode)
 {
 ScrnInfoPtr pScrn = output-scrn;
 
@@ -600,7 +604,8 @@ via_dp_detect(xf86OutputPtr output)
 mon = xf86OutputGetEDID(output, pVia-pI2CBus2);
 if (mon  DIGITAL(mon-features.input_type)) {
 xf86OutputSetEDID(output, mon);
-DEBUG(xf86DrvMsg(pScrn-scrnIndex, X_PROBED, DDC pI2CBus2 detected a 
DP\n));
+DEBUG(xf86DrvMsg(pScrn-scrnIndex, X_PROBED,
+ DDC pI2CBus2 detected a DP\n));
 status = XF86OutputStatusConnected;
 }
 return status;
@@ -678,7 +683,7 @@ via_analog_create_resources(xf86OutputPtr output)
 #ifdef RANDR_12_INTERFACE
 static Bool
 via_analog_set_property(xf86OutputPtr output, Atom property

[Openchrome-devel] [xf86-video-openchrome]X driver for VIA IGPs branch master updated. release_0_3_3-37-g40dd677

2015-01-18 Thread Xavier Bachelot 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project X driver for VIA IGPs.

The branch, master has been updated
   via  40dd677c721f4d1b1f7f29e7745fc81402abeb8b (commit)
  from  98d43c48d100a02819397cf951ae8061f1f6124c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 40dd677c721f4d1b1f7f29e7745fc81402abeb8b
Author: Xavier Bachelot xav...@bachelot.org
Date:   Sun Jan 18 21:18:50 2015 +0100

Cosmetic : Wrap lines and remove tabs indentation.

Signed-off-by: Xavier Bachelot xav...@bachelot.org

---

Summary of changes:
 src/via_outputs.c |  202 -
 1 file changed, 107 insertions(+), 95 deletions(-)


hooks/post-receive
-- 
X driver for VIA IGPs
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] xf86-video-openchrome: src/via_outputs.c

2015-01-13 Thread Xavier Bachelot 
 src/via_outputs.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit 8ff8235260c035b960c3552df25a9784e1049f24
Author: Xavier Bachelot xav...@bachelot.org
Date:   Tue Jan 13 22:06:44 2015 +0100

Make via_dvi_set_property return TRUE.
Other via_*_set_property just got fixed in 
271c716f2060bc04a5ca8324c0d2c27473463206

diff --git a/src/via_outputs.c b/src/via_outputs.c
index 71b059b..d488130 100644
--- a/src/via_outputs.c
+++ b/src/via_outputs.c
@@ -871,7 +871,7 @@ static Bool
 via_dvi_set_property(xf86OutputPtr output, Atom property,
RRPropertyValuePtr value)
 {
-return FALSE;
+return TRUE;
 }
 
 static Bool
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [xf86-video-openchrome]X driver for VIA IGPs branch master updated. release_0_3_3-4-gc04bf57

2013-06-22 Thread Xavier Bachelot 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project X driver for VIA IGPs.

The branch, master has been updated
   via  c04bf57c460a6c7ddf00377ec065bb0efe188fc8 (commit)
  from  200cdb68353e638c78582c0ae571e59c96cfea64 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit c04bf57c460a6c7ddf00377ec065bb0efe188fc8
Author: Xavier Bachelot xav...@bachelot.org
Date:   Sat Jun 22 17:10:01 2013 +0200

Shuttle MK40V (reported by Belkacem Houari)

---

Summary of changes:
 src/via_id.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)


hooks/post-receive
-- 
X driver for VIA IGPs
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] xf86-video-openchrome: 2 commits - src/via_driver.h src/via_memcpy.c

2013-06-03 Thread Xavier Bachelot 
 src/via_driver.h |   11 +++
 src/via_memcpy.c |   12 
 2 files changed, 11 insertions(+), 12 deletions(-)

New commits:
commit 237233d14346604488785a9899f01df044245949
Author: Jared McNeill jmcne...@netbsd.org
Date:   Mon Jun 3 20:52:47 2013 +0200

Remove a couple '#ifdef linux's to let the driver use optimized memcpy
functions on NetBSD for video copy. Gives nearly 2x performance on my
test system (previously kernel memcpy was always used):

CHROME(0): Benchmarking video copy.  Less time is better.
CHROME(0): Timed   libc YUV420 copy... 3000272. Throughput: 315.6 MiB/s.
CHROME(0): Timed kernel YUV420 copy... 3024946. Throughput: 313.0 MiB/s.
CHROME(0): TimedSSE YUV420 copy... 1591352. Throughput: 595.0 MiB/s.
CHROME(0): TimedMMX YUV420 copy... 2566279. Throughput: 369.0 MiB/s.
CHROME(0): Ditching 3DNow! YUV420 copy. Not supported by CPU.
CHROME(0): Timed   MMX2 YUV420 copy... 1696662. Throughput: 558.1 MiB/s.
CHROME(0): Using SSE YUV42X copy for video.

diff --git a/src/via_memcpy.c b/src/via_memcpy.c
index d4eb804..8ef0e9f 100644
--- a/src/via_memcpy.c
+++ b/src/via_memcpy.c
@@ -309,8 +309,6 @@
 }
 
 
-#if !defined(__i386__) || (defined(linux)  defined(__i386__))
-
 static void
 libc_YUV42X(unsigned char *dst, const unsigned char *src,
 int dstPitch, int w, int h, int yuv422)
@@ -348,8 +346,6 @@ libc_YUV42X(unsigned char *dst, const unsigned char *src,
 }
 }
 }
-#endif
-
 
 #ifdef __i386__
 
@@ -415,7 +411,6 @@ kernel_YUV42X(unsigned char *dst, const unsigned char *src,
 }
 }
 
-#ifdef linux
 PREFETCH_FUNC(sse, SSE, SSE,, FENCE)
 PREFETCH_FUNC(mmxext, MMXEXT, SSE, EMMS, FENCEMMS)
 PREFETCH_FUNC(now, MMX, NOW, FEMMS, FEMMS)
@@ -515,7 +510,6 @@ cpuValid(const char *cpuinfo, char **flags)
 }
 return 0;
 }
-#endif /* linux */
 
 /*
  * Benchmark the video copy routines and choose the fastest.
@@ -525,7 +519,6 @@ viaVidCopyInit(char *copyType, ScreenPtr pScreen)
 {
 ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
 
-#ifdef linux
 char buf[BSIZ];
 unsigned char *buf1, *buf2, *buf3;
 char *tmpBuf, *endBuf;
@@ -641,11 +634,6 @@ viaVidCopyInit(char *copyType, ScreenPtr pScreen)
Using %s YUV42X copy for %s.\n,
mcFunctions[bestSoFar].mName, copyType);
 return mcFunctions[bestSoFar].mFunc;
-#else
-xf86DrvMsg(pScrn-scrnIndex, X_INFO,
-   Using Linux kernel memcpy for video.\n);
-return kernel_YUV42X;
-#endif /* linux */
 }
 
 #else
commit 78b9f43ca8d04383a83659619d70f61688568366
Author: Christos Zoulas chris...@netbsd.org
Date:   Mon Jun 3 20:50:45 2013 +0200

Add missing prototypes

diff --git a/src/via_driver.h b/src/via_driver.h
index f82fdda..dfe91fc 100644
--- a/src/via_driver.h
+++ b/src/via_driver.h
@@ -519,4 +519,15 @@ Bool VIADRIBufferInit(ScrnInfoPtr pScrn);
 
 #endif /* HAVE_DRI */
 
+int viaOffScreenLinear(struct buffer_object *obj, ScrnInfoPtr pScrn, unsigned 
long size);
+void viaShowCursor(ScrnInfoPtr pScrn);
+void viaHideCursor(ScrnInfoPtr pScrn);
+Bool viaHWCursorInit(ScreenPtr pScreen);
+void ViaDisplaySetStreamOnCRT(ScrnInfoPtr pScrn, Bool primary);
+void ViaDisplaySetStreamOnDFP(ScrnInfoPtr pScrn, Bool primary);
+void ViaDisplaySetStreamOnDVO(ScrnInfoPtr pScrn, int port, Bool primary);
+void ViaDisplayEnableSimultaneous(ScrnInfoPtr pScrn);
+void ViaDisplayEnableCRT(ScrnInfoPtr pScrn);
+void ViaDisplayEnableDVO(ScrnInfoPtr pScrn, int port);
+
 #endif /* _VIA_DRIVER_H_ */
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] xf86-video-openchrome: 4 commits - configure.ac NEWS src/via_outputs.c src/xvmc/xf86dri.c

2013-05-23 Thread Xavier Bachelot 
 NEWS   |8 
 configure.ac   |2 +-
 src/via_outputs.c  |2 +-
 src/xvmc/xf86dri.c |   14 +++---
 4 files changed, 21 insertions(+), 5 deletions(-)

New commits:
commit 0c17f81ad43d42958ab3871c9b5c5e9cea402256
Author: Xavier Bachelot xav...@bachelot.org
Date:   Wed May 22 18:58:48 2013 +0200

Bump version to 0.3.3

diff --git a/NEWS b/NEWS
index 917aea0..eb1b8f8 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,11 @@
+openchrome 0.3.3 (23/05/2013)
+-
+
+This is a bugfix release.
+- Fix integer overflow in libchromeXvMC (CVE-2013-1994).
+- Various bug fixes and improvements.
+
+
 openchrome 0.3.2 (27/03/2013)
 -
 
diff --git a/configure.ac b/configure.ac
index 238e3af..b13cb2c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -23,7 +23,7 @@
 # Initialize Autoconf
 AC_PREREQ(2.57)
 AC_INIT([xf86-video-openchrome],
-[0.3.2],
+[0.3.3],
 
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorgcomponent=Driver/openchrome],
 [xf86-video-openchrome])
 
commit db309e3cd87a1279e8b592a692390755c528de4f
Author: Alan Coopersmith alan.coopersm...@oracle.com
Date:   Sat Apr 13 20:57:07 2013 -0700

integer overflow in uniDRIGetClientDriverName() in libchromeXvMC* 
[CVE-2013-1994 2/2]

clientDriverNameLength is a CARD32 and needs to be bounds checked before
adding one to it to come up with the total size to allocate, to avoid
integer overflow leading to underallocation and writing data from the
network past the end of the allocated buffer.

Reported-by: Ilja Van Sprundel ivansprun...@ioactive.com
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com

diff --git a/src/xvmc/xf86dri.c b/src/xvmc/xf86dri.c
index fba7583..c5702ec 100644
--- a/src/xvmc/xf86dri.c
+++ b/src/xvmc/xf86dri.c
@@ -314,8 +314,11 @@ uniDRIGetClientDriverName(dpy, screen, 
ddxDriverMajorVersion,
 *ddxDriverPatchVersion = rep.ddxDriverPatchVersion;
 
 if (rep.length) {
-   if (!(*clientDriverName =
-   (char *)Xcalloc(rep.clientDriverNameLength + 1, 1))) {
+   if (rep.clientDriverNameLength  INT_MAX)
+   *clientDriverName = Xcalloc(rep.clientDriverNameLength + 1, 1);
+   else
+   *clientDriverName = NULL;
+   if (*clientDriverName == NULL) {
_XEatData(dpy, ((rep.clientDriverNameLength + 3)  ~3));
UnlockDisplay(dpy);
SyncHandle();
commit 68bf50ce4903ec93da59cea78e063ed7c3882d3e
Author: Alan Coopersmith alan.coopersm...@oracle.com
Date:   Sat Apr 13 20:49:43 2013 -0700

integer overflow in uniDRIOpenConnection() in libchromeXvMC* [CVE-2013-1994 
1/2]

busIdStringLength is a CARD32 and needs to be bounds checked before adding
one to it to come up with the total size to allocate, to avoid integer
overflow leading to underallocation and writing data from the network past
the end of the allocated buffer.

Reported-by: Ilja Van Sprundel ivansprun...@ioactive.com
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com

diff --git a/src/xvmc/xf86dri.c b/src/xvmc/xf86dri.c
index 1feb232..fba7583 100644
--- a/src/xvmc/xf86dri.c
+++ b/src/xvmc/xf86dri.c
@@ -42,6 +42,7 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 #include X11/extensions/Xext.h
 #include X11/extensions/extutil.h
 #include xf86dristr.h
+#include limits.h
 
 static XExtensionInfo _xf86dri_info_data;
 static XExtensionInfo *xf86dri_info = _xf86dri_info_data;
@@ -203,7 +204,11 @@ uniDRIOpenConnection(dpy, screen, hSAREA, busIdString)
 }
 #endif
 if (rep.length) {
-   if (!(*busIdString = (char *)Xcalloc(rep.busIdStringLength + 1, 1))) {
+   if (rep.busIdStringLength  INT_MAX)
+   *busIdString = Xcalloc(rep.busIdStringLength + 1, 1);
+   else
+   *busIdString = NULL;
+   if (*busIdString == NULL) {
_XEatData(dpy, ((rep.busIdStringLength + 3)  ~3));
UnlockDisplay(dpy);
SyncHandle();
commit 50cef9490c6a128613c5b9f3f19ef2e803088983
Author: Xavier Bachelot xav...@bachelot.org
Date:   Tue May 21 21:24:41 2013 +0200

Probe TV encoder on all but the P4M900, unless we know the board has a TV 
encoder.

Probing the TV encoder on the P4M900 chipset family when there is no such 
encoder is not safe. It is safe however on all other platforms.

diff --git a/src/via_outputs.c b/src/via_outputs.c
index 7e0c5e4..1271fc8 100644
--- a/src/via_outputs.c
+++ b/src/via_outputs.c
@@ -885,7 +885,7 @@ ViaOutputsDetect(ScrnInfoPtr pScrn)
  * disables the panel on P4M900
  */
 /* TV encoder */
-if (pVia-ActiveDevice  VIA_DEVICE_TV)
+if ((pVia-Chipset != VIA_P4M900) || (pVia-ActiveDevice  VIA_DEVICE_TV))
 via_tv_init(pScrn);
 
 if (pVia-ActiveDevice  VIA_DEVICE_DFP) {
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org

[Openchrome-devel] [xf86-video-openchrome]X driver for VIA IGPs branch master updated. release_0_3_2-14-g0c17f81

2013-05-23 Thread Xavier Bachelot 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project X driver for VIA IGPs.

The branch, master has been updated
   via  0c17f81ad43d42958ab3871c9b5c5e9cea402256 (commit)
   via  db309e3cd87a1279e8b592a692390755c528de4f (commit)
   via  68bf50ce4903ec93da59cea78e063ed7c3882d3e (commit)
   via  50cef9490c6a128613c5b9f3f19ef2e803088983 (commit)
  from  79731f58281eb8782f8291a3d9375cb3f7691a13 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 0c17f81ad43d42958ab3871c9b5c5e9cea402256
Author: Xavier Bachelot xav...@bachelot.org
Date:   Wed May 22 18:58:48 2013 +0200

Bump version to 0.3.3

commit db309e3cd87a1279e8b592a692390755c528de4f
Author: Alan Coopersmith alan.coopersm...@oracle.com
Date:   Sat Apr 13 20:57:07 2013 -0700

integer overflow in uniDRIGetClientDriverName() in libchromeXvMC* 
[CVE-2013-1994 2/2]

clientDriverNameLength is a CARD32 and needs to be bounds checked before
adding one to it to come up with the total size to allocate, to avoid
integer overflow leading to underallocation and writing data from the
network past the end of the allocated buffer.

Reported-by: Ilja Van Sprundel ivansprun...@ioactive.com
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com

commit 68bf50ce4903ec93da59cea78e063ed7c3882d3e
Author: Alan Coopersmith alan.coopersm...@oracle.com
Date:   Sat Apr 13 20:49:43 2013 -0700

integer overflow in uniDRIOpenConnection() in libchromeXvMC* [CVE-2013-1994 
1/2]

busIdStringLength is a CARD32 and needs to be bounds checked before adding
one to it to come up with the total size to allocate, to avoid integer
overflow leading to underallocation and writing data from the network past
the end of the allocated buffer.

Reported-by: Ilja Van Sprundel ivansprun...@ioactive.com
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com

commit 50cef9490c6a128613c5b9f3f19ef2e803088983
Author: Xavier Bachelot xav...@bachelot.org
Date:   Tue May 21 21:24:41 2013 +0200

Probe TV encoder on all but the P4M900, unless we know the board has a TV 
encoder.

Probing the TV encoder on the P4M900 chipset family when there is no such 
encoder is not safe. It is safe however on all other platforms.

---

Summary of changes:
 NEWS   |8 
 configure.ac   |2 +-
 src/via_outputs.c  |2 +-
 src/xvmc/xf86dri.c |   14 +++---
 4 files changed, 21 insertions(+), 5 deletions(-)


hooks/post-receive
-- 
X driver for VIA IGPs
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] xf86-video-openchrome: Changes to 'refs/tags/release_0_3_3'

2013-05-23 Thread Xavier Bachelot 
Tag 'release_0_3_3' created by Xavier Bachelot xav...@bachelot.org at 
2013-05-23 16:10 -0700

release 0.3.3

Changes since release_0_3_2:
Alan Coopersmith (2):
  integer overflow in uniDRIOpenConnection() in libchromeXvMC* 
[CVE-2013-1994 1/2]
  integer overflow in uniDRIGetClientDriverName() in libchromeXvMC* 
[CVE-2013-1994 2/2]

James Simmons (8):
  via_xf86crtc_resize can handle both UMS and KMS modes so we can remove 
drmmode_xf86crtc_resize.
  Enable xorg driver to recieve hotplug events.
  drmmode_set_mode_major does this for us so no need to do it here
  Integrate the different formats now supported by libdrm. This makes 
allocating buffers for KMS planes in the future much easier
  In our driver in order to support both KMS and UMS we can't call 
drmmode_set_mode_major directly but instead
  Fix the problems with UMS multiple screen handling. KMS still has problems
  Patch from Krummenacher max.krummenac...@toradex.com
  Our xorg driver has moved to using drm_fourcc.h but not all distros have 
a new enough libdrm so building can fail. We place a copy in our source tree to 
ensure building and this header doesn't change to often

Xavier Bachelot (4):
  Biostar Viotech 3100+ (reported by J. Scott Heppler)
  make iga[12]_crtc_mode_fixup more verbose when the mode is rejected.
  Probe TV encoder on all but the P4M900, unless we know the board has a TV 
encoder.
  Bump version to 0.3.3

---
 NEWS   |8 +
 configure.ac   |2 
 src/Makefile.am|6 -
 src/drm_fourcc.h   |  130 +++
 src/via_display.c  |   47 ---
 src/via_driver.c   |  146 +++
 src/via_driver.h   |1 
 src/via_id.c   |1 
 src/via_kms.c  |  221 ++---
 src/via_lvds.c |3 
 src/via_memmgr.c   |   32 ++-
 src/via_memmgr.h   |2 
 src/via_outputs.c  |2 
 src/via_ums.h  |4 
 src/xvmc/xf86dri.c |   14 ++-
 15 files changed, 368 insertions(+), 251 deletions(-)
---
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [xf86-video-openchrome]X driver for VIA IGPs annotated tag release_0_3_3 created. release_0_3_3

2013-05-23 Thread Xavier Bachelot 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project X driver for VIA IGPs.

The annotated tag, release_0_3_3 has been created
at  1dfa38149a5da554fb882caf7103ca33223bba5a (tag)
   tagging  0c17f81ad43d42958ab3871c9b5c5e9cea402256 (commit)
  replaces  release_0_3_2
 tagged by  Xavier Bachelot
on  Thu May 23 17:10:41 2013 +0200

- Log -
release 0.3.3

Alan Coopersmith (2):
  integer overflow in uniDRIOpenConnection() in libchromeXvMC* 
[CVE-2013-1994 1/2]
  integer overflow in uniDRIGetClientDriverName() in libchromeXvMC* 
[CVE-2013-1994 2/2]

James Simmons (8):
  via_xf86crtc_resize can handle both UMS and KMS modes so we can remove 
drmmode_xf86crtc_resize.
  Enable xorg driver to recieve hotplug events.
  drmmode_set_mode_major does this for us so no need to do it here
  Integrate the different formats now supported by libdrm. This makes 
allocating buffers for KMS planes in the future much easier
  In our driver in order to support both KMS and UMS we can't call 
drmmode_set_mode_major directly but instead
  Fix the problems with UMS multiple screen handling. KMS still has problems
  Patch from Krummenacher max.krummenac...@toradex.com
  Our xorg driver has moved to using drm_fourcc.h but not all distros have 
a new enough libdrm so building can fail. We place a copy in our source tree to 
ensure building and this header doesn't change to often

Xavier Bachelot (4):
  Biostar Viotech 3100+ (reported by J. Scott Heppler)
  make iga[12]_crtc_mode_fixup more verbose when the mode is rejected.
  Probe TV encoder on all but the P4M900, unless we know the board has a TV 
encoder.
  Bump version to 0.3.3

---


hooks/post-receive
-- 
X driver for VIA IGPs
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [ANNOUNCE] xf86-video-openchrome 0.3.3

2013-05-23 Thread Xavier Bachelot 
Hi,

xf86-video-openchrome 0.3.3 has been released.

This is a bugfix release. It includes :
- Fix integer overflow in libchromeXvMC (CVE-2013-1994).
- Various bug fixes and improvements.

Get the tarball from
http://xorg.freedesktop.org/archive/individual/driver/

xf86-video-openchrome-0.3.3.tar.bz2
MD5: f21abcdf87f73b5b547491281e894c87
SHA1: 1f7b23d4ed53417eda5c6730486b36812f469295

xf86-video-openchrome-0.3.3.tar.gz
MD5: 288dddcd2c3de417d4bb4985a91c3f61
SHA1: d02fb6a4318f31095e552cf1f34b486b4ef0fcf7

Kind regards,
the Openchrome team
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [PATCH] Probe TV encoder on all but the P4M900, unless we know the board has a TV encoder.

2013-05-22 Thread Xavier Bachelot 
Probing the TV encoder on the P4M900 chipset family when there is no such
encoder is not safe. It is safe however on all other platforms.
---
 src/via_outputs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/via_outputs.c b/src/via_outputs.c
index 7e0c5e4..1271fc8 100644
--- a/src/via_outputs.c
+++ b/src/via_outputs.c
@@ -885,7 +885,7 @@ ViaOutputsDetect(ScrnInfoPtr pScrn)
  * disables the panel on P4M900
  */
 /* TV encoder */
-if (pVia-ActiveDevice  VIA_DEVICE_TV)
+if ((pVia-Chipset != VIA_P4M900) || (pVia-ActiveDevice  VIA_DEVICE_TV))
 via_tv_init(pScrn);
  if (pVia-ActiveDevice  VIA_DEVICE_DFP) {
-- 
1.8.1.4

___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] xf86-video-openchrome: src/via_display.c

2013-05-16 Thread Xavier Bachelot 
 src/via_display.c |   28 
 1 file changed, 24 insertions(+), 4 deletions(-)

New commits:
commit 541a3c1765e71af91e1319a3ab165ac37a0fd17d
Author: Xavier Bachelot xav...@bachelot.org
Date:   Wed Apr 24 19:38:02 2013 +0200

make iga[12]_crtc_mode_fixup more verbose when the mode is rejected.

diff --git a/src/via_display.c b/src/via_display.c
index 267a9c1..82cd8b2 100644
--- a/src/via_display.c
+++ b/src/via_display.c
@@ -908,16 +908,26 @@ iga1_crtc_mode_fixup(xf86CrtcPtr crtc, DisplayModePtr 
mode,
 ScrnInfoPtr pScrn = crtc-scrn;
 VIAPtr pVia = VIAPTR(pScrn);
 CARD32 temp;
+ModeStatus modestatus;
 
 if (pVia-pVbe)
 return TRUE;
 
 if ((mode-Clock  pScrn-clockRanges-minClock) ||
-(mode-Clock  pScrn-clockRanges-maxClock))
+(mode-Clock  pScrn-clockRanges-maxClock)) {
+xf86DrvMsg(pScrn-scrnIndex, X_INFO,
+   Clock for mode \%s\ outside of allowed range (%u (%u - 
%u))\n,
+   mode-name, mode-Clock, pScrn-clockRanges-minClock,
+   pScrn-clockRanges-maxClock);
 return FALSE;
+}
 
-if (ViaFirstCRTCModeValid(pScrn, mode) != MODE_OK)
+modestatus = ViaFirstCRTCModeValid(pScrn, mode);
+if (modestatus != MODE_OK) {
+xf86DrvMsg(pScrn-scrnIndex, X_INFO, Not using mode \%s\ : %s.\n,
+   mode-name, xf86ModeStatusToString(modestatus));
 return FALSE;
+}
 
 temp = mode-CrtcHDisplay * mode-CrtcVDisplay * mode-VRefresh *
 (pScrn-bitsPerPixel  3);
@@ -1309,16 +1319,26 @@ iga2_crtc_mode_fixup(xf86CrtcPtr crtc, DisplayModePtr 
mode,
 ScrnInfoPtr pScrn = crtc-scrn;
 VIAPtr pVia = VIAPTR(pScrn);
 CARD32 temp;
+ModeStatus modestatus;
 
 if (pVia-pVbe)
 return TRUE;
 
 if ((mode-Clock  pScrn-clockRanges-minClock) ||
-(mode-Clock  pScrn-clockRanges-maxClock))
+(mode-Clock  pScrn-clockRanges-maxClock)) {
+xf86DrvMsg(pScrn-scrnIndex, X_INFO,
+   Clock for mode \%s\ outside of allowed range (%u (%u - 
%u))\n,
+   mode-name, mode-Clock, pScrn-clockRanges-minClock,
+   pScrn-clockRanges-maxClock);
 return FALSE;
+}
 
-if (ViaSecondCRTCModeValid(pScrn, mode) != MODE_OK)
+modestatus = ViaFirstCRTCModeValid(pScrn, mode);
+if (modestatus != MODE_OK) {
+xf86DrvMsg(pScrn-scrnIndex, X_INFO, Not using mode \%s\ : %s.\n,
+   mode-name, xf86ModeStatusToString(modestatus));
 return FALSE;
+}
 
 temp = mode-CrtcHDisplay * mode-CrtcVDisplay * mode-VRefresh *
 (pScrn-bitsPerPixel  3);
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [xf86-video-openchrome]X driver for VIA IGPs branch master updated. release_0_3_2-6-g541a3c1

2013-05-16 Thread Xavier Bachelot 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project X driver for VIA IGPs.

The branch, master has been updated
   via  541a3c1765e71af91e1319a3ab165ac37a0fd17d (commit)
  from  3808a3b88e474f9549b06388c8bc323c4cb0b4b9 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 541a3c1765e71af91e1319a3ab165ac37a0fd17d
Author: Xavier Bachelot xav...@bachelot.org
Date:   Wed Apr 24 19:38:02 2013 +0200

make iga[12]_crtc_mode_fixup more verbose when the mode is rejected.

---

Summary of changes:
 src/via_display.c |   28 
 1 files changed, 24 insertions(+), 4 deletions(-)


hooks/post-receive
-- 
X driver for VIA IGPs
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] xf86-video-openchrome: src/via_id.c

2013-04-03 Thread Xavier Bachelot 
 src/via_id.c |1 +
 1 file changed, 1 insertion(+)

New commits:
commit 03c1b92d6b84af47fad90a2ade206a5c9a3b7e9a
Author: Xavier Bachelot xav...@bachelot.org
Date:   Wed Apr 3 23:25:38 2013 +0200

Biostar Viotech 3100+ (reported by J. Scott Heppler)

diff --git a/src/via_id.c b/src/via_id.c
index bb18e84..1053293 100644
--- a/src/via_id.c
+++ b/src/via_id.c
@@ -205,6 +205,7 @@ static struct ViaCardIdStruct ViaCardId[] = {
 {Neo Endura 540SLe, VIA_P4M900,  0x1558, 0x5408, 
VIA_DEVICE_CRT | VIA_DEVICE_LCD},
 {Clevo M54xSR,  VIA_P4M900,  0x1558, 0x5409, 
VIA_DEVICE_CRT | VIA_DEVICE_LCD},
 {Biostar P4M900M-M7 SE, VIA_P4M900,  0x1565, 0x1207, 
VIA_DEVICE_CRT},
+{Biostar Viotech 3100+, VIA_P4M900,  0x1565, 0x1209, 
VIA_DEVICE_CRT},
 {Fujitsu/Siemens Amilo Pro V3515,   VIA_P4M900,  0x1734, 0x10CB, 
VIA_DEVICE_CRT | VIA_DEVICE_LCD},
 {Fujitsu/Siemens Amilo Li1705,  VIA_P4M900,  0x1734, 0x10F7, 
VIA_DEVICE_CRT | VIA_DEVICE_LCD},
 {ASRock P4VM900-SATA2,  VIA_P4M900,  0x1849, 0x3371, 
VIA_DEVICE_CRT},
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [xf86-video-openchrome]X driver for VIA IGPs annotated tag release_0_3_2 created. release_0_3_2

2013-03-27 Thread Xavier Bachelot 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project X driver for VIA IGPs.

The annotated tag, release_0_3_2 has been created
at  349ebb63a9379b250ca8f5755770051c6d049162 (tag)
   tagging  9bc4026a4069c1ab5b595315dac4a03d1b65129a (commit)
  replaces  release_0_3_1
 tagged by  Xavier Bachelot
on  Wed Mar 27 22:56:09 2013 +0100

- Log -
release 0.3.2

Bartosz Kosiorek (3):
  registers dumper improvements
  Fixes to reenable EXA composite support. Currently EXA crashes
  Fix Xv bandwidth check when no vertical refresh is available

Harry de Boer (4):
  Fix VT1625 output sensing. VT1625DACSenseI2C was using the same code as 
VT162xDACSenseI2C but the DAC sensing bit is in a different register for the 
VT1625. Also adds support for the VT1625S which has only four DACs.
  VT1625 register count is 0x82
  Set possible_crtcs to allow tv outputs to be connected to crtcs.
  Return valid DisplayModePtr list for tv outputs. When creating a list of 
DisplayModePtr the -next and -prev pointers should point to the next/previous 
item in the list or only the first modeline will be recognised. This patch 
changes via_tv_get_modes to use the xf86ModesAdd and xf86DuplicateMode helpers 
to create correct modeline lists from a DisplayModeRec array.

James Simmons (16):
  When setting a new video mode we were assuming the offset into the frame 
buffer was 0,0 which is not always the case
  The default timeouts for values for I2C are way to small for the defaults 
xorg server sets. We set them to the VESA DDC specs values instead.
  Setup the basic IGA registers. This is needed to allow CLE266 to work in 
Non Legacy Modesetting.
  ViaDisplayInit called at startup broke VT switching. Instead I call 
ViaDisplayInit in VIARestore which allows CLE266 to work without legacy mode
  XSERVER_LIBPCIACCESS is now decrepide but we need to handle older 
platforms (rhel5) so HAVE_PCIACCESS was created. This patch allows us to use 
libpciaccess 0.11 or better or work around the lack of libpciaccess.
  Sometimes we fail to get a EDID from a VGA monitor but a real display is 
attached. In this case we look to see if a vblank is raised by the analog 
monitor and report it as detected
  Do not support earlier libdrm versions that lack KMS support.
  Fix a double free when exiting the xorg server
  Doh, shouldn't code when sleepy. Free the TV i2c struct only we still 
have a pBIOSInfo struct left
  Fix a long standing issues of detecting the proper amount of VRAM on the 
P4M800 devices. We can tell it is a p4m800 versus a km400 by what pci bridge it 
has and reading the proper pic function
  As the comment suggested in via_outputs.c probing the 3rd i2c bug locks 
up the P4M900. So we re-enable the via_card_id handling of what outputs to test 
for to get around this problem.
  Add Nec Powermate VL5 ViaCardId data to support this device
  Support older X servers for RHEL5
  Allow via_output.c to build without C99 mode
  miInitializeBackingStore no longer exist in xorg server 1.14. Removing 
causes no regression in earlier versions from my testing
  Rename GEM data structure in the fashion of other drm driver apis

Pascal Ermster (1):
  Change AM_CONFIG_HEADER to AC_CONFIG_HEADERS

Xavier Bachelot (14):
  Fix typo in registers description
  Biostar Viotech 3200+
  Fix typo
  Change to new mailing list address
  Fix indentation
  Fix registers description
  Fix CN400 Xv on secondary
  typo
  When the card id is unknown, don't check CLE266 revision if the chipset 
is not CLE266
  Fujitsu Futro A300 (reported by Alberto Asuero)
  Revert CLE266 to legacy modeswitch
  Add an explicit message for KMS support configure check
  Hardcode panel size for the XO
  bump version to 0.3.2

---


hooks/post-receive
-- 
X driver for VIA IGPs
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [ANNOUNCE] xf86-video-openchrome 0.3.2

2013-03-27 Thread Xavier Bachelot 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

xf86-video-openchrome 0.3.2 has been released.

This is a bugfix release. It includes :
- - EXA fixes. Compositing is now enabled again.
- - TV out fixes and enhancements.
- - Fix memory detection on P4M800.
- - Fix for lockup when probing some I2C bus on P4M900.
- - VGA out probing with Vblank.
- - Fix building with autoconf 1.13.1.
- - Fix for X server 1.14.
- - Various bug fixes and improvements.

Get the tarball from
http://xorg.freedesktop.org/archive/individual/driver/

xf86-video-openchrome-0.3.2.tar.bz2
MD5: 172509a5a7ab5c89ff09501d733cf5f6
SHA1: e5be9a8200410b3e3e66349bab4c8acd1ead4402

xf86-video-openchrome-0.3.2.tar.gz
MD5: a6bcabfc847201b4b44d60a6ca515716
SHA1: f1dfc2f642a19c7110e115f2d1ef4c5ad045335e

Kind regards,
the Openchrome team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)

iD8DBQFRU3vzuxLT9ttCNJARAp4KAJ9jz2xKcbMBa6oviriZaAiTm2i3aACfWq4Q
feGU65HXBsd5n9mhrX7YNkw=
=l9sd
-END PGP SIGNATURE-
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] xf86-video-openchrome: src/via_lvds.c

2013-03-04 Thread Xavier Bachelot 
 src/via_lvds.c |8 
 1 file changed, 8 insertions(+)

New commits:
commit 396a209cd1988ece56d556d756c062b0120991d1
Author: Xavier Bachelot xav...@bachelot.org
Date:   Mon Feb 18 22:45:11 2013 +0100

Hardcode panel size for the XO

diff --git a/src/via_lvds.c b/src/via_lvds.c
index d7d8225..e4e5cdf 100644
--- a/src/via_lvds.c
+++ b/src/via_lvds.c
@@ -1301,6 +1301,14 @@ via_lvds_detect(xf86OutputPtr output)
 VIAPtr pVia = VIAPTR(pScrn);
 vgaHWPtr hwp = VGAHWPTR(pScrn);
 
+/* Hardcode panel size for the XO */
+if (pVia-Id-String == OLPC XO 1.5) {
+panel-NativeWidth = 1200;
+panel-NativeHeight = 900;
+status = XF86OutputStatusConnected;
+return status;
+}
+
 if (!pVia-UseLegacyModeSwitch) {
 /* First try to get the mode from EDID. */
 if (!panel-NativeWidth || !panel-NativeHeight) {
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [xf86-video-openchrome]X driver for VIA IGPs branch master updated. release_0_3_1-34-g396a209

2013-03-04 Thread Xavier Bachelot 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project X driver for VIA IGPs.

The branch, master has been updated
   via  396a209cd1988ece56d556d756c062b0120991d1 (commit)
  from  c27f9fedd1ffb3462154dc309afdf10b5b6ff50d (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 396a209cd1988ece56d556d756c062b0120991d1
Author: Xavier Bachelot xav...@bachelot.org
Date:   Mon Feb 18 22:45:11 2013 +0100

Hardcode panel size for the XO

---

Summary of changes:
 src/via_lvds.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)


hooks/post-receive
-- 
X driver for VIA IGPs
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] xf86-video-openchrome: configure.ac

2013-03-04 Thread Xavier Bachelot 
 configure.ac |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit a925749eb21ba9e2e58845bc91554a09f20322ca
Author: Pascal Ermster bugs.freedesktop@hardfalcon.net
Date:   Mon Mar 4 19:53:51 2013 +0100

Change AM_CONFIG_HEADER to AC_CONFIG_HEADERS

diff --git a/configure.ac b/configure.ac
index b0bc0e9..3b07214 100644
--- a/configure.ac
+++ b/configure.ac
@@ -38,7 +38,7 @@ AC_DEFINE_UNQUOTED([VIA_PATCHLEVEL],
[Patch version])
 
 AC_CONFIG_SRCDIR([Makefile.am])
-AM_CONFIG_HEADER([config.h])
+AC_CONFIG_HEADERS([config.h])
 AC_CONFIG_AUX_DIR(.)
 
 AM_INIT_AUTOMAKE([foreign dist-bzip2])
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [xf86-video-openchrome]X driver for VIA IGPs branch master updated. release_0_3_1-35-ga925749

2013-03-04 Thread Xavier Bachelot 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project X driver for VIA IGPs.

The branch, master has been updated
   via  a925749eb21ba9e2e58845bc91554a09f20322ca (commit)
  from  396a209cd1988ece56d556d756c062b0120991d1 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit a925749eb21ba9e2e58845bc91554a09f20322ca
Author: Pascal Ermster bugs.freedesktop@hardfalcon.net
Date:   Mon Mar 4 19:53:51 2013 +0100

Change AM_CONFIG_HEADER to AC_CONFIG_HEADERS

---

Summary of changes:
 configure.ac |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


hooks/post-receive
-- 
X driver for VIA IGPs
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [PATCH] Hardcode panel size for the XO

2013-02-18 Thread Xavier Bachelot 
---
 src/via_lvds.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/via_lvds.c b/src/via_lvds.c
index d7d8225..e4e5cdf 100644
--- a/src/via_lvds.c
+++ b/src/via_lvds.c
@@ -1301,6 +1301,14 @@ via_lvds_detect(xf86OutputPtr output)
 VIAPtr pVia = VIAPTR(pScrn);
 vgaHWPtr hwp = VGAHWPTR(pScrn);
+/* Hardcode panel size for the XO */
+if (pVia-Id-String == OLPC XO 1.5) {
+panel-NativeWidth = 1200;
+panel-NativeHeight = 900;
+status = XF86OutputStatusConnected;
+return status;
+}
+
 if (!pVia-UseLegacyModeSwitch) {
 /* First try to get the mode from EDID. */
 if (!panel-NativeWidth || !panel-NativeHeight) {
-- 
1.8.1.2

___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel

[Openchrome-devel] [xf86-video-openchrome]X driver for VIA IGPs branch, master, updated. release_0_3_1-8-ga9f13be

2012-11-01 Thread Xavier Bachelot 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project X driver for VIA IGPs.

The branch, master has been updated
   via  a9f13be7cfeefb4842f4ac378dc6f4eea3dd8ac2 (commit)
   via  7311799ea75e49001efdcca8d565aa76c7bf297c (commit)
   via  e3685312c306c14d16dc399239a6bcd8ed0d7c86 (commit)
  from  dbed0fcbfa44f6433a4d87177d12c3a9fe73a40e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit a9f13be7cfeefb4842f4ac378dc6f4eea3dd8ac2
Author: Xavier Bachelot xav...@bachelot.org
Date:   Thu Nov 1 21:20:07 2012 +0100

Fix indentation

commit 7311799ea75e49001efdcca8d565aa76c7bf297c
Author: Xavier Bachelot xav...@bachelot.org
Date:   Thu Nov 1 21:16:17 2012 +0100

Change to new mailing list address

commit e3685312c306c14d16dc399239a6bcd8ed0d7c86
Author: Xavier Bachelot xav...@bachelot.org
Date:   Mon Oct 8 22:15:26 2012 +0200

Fix typo

---

Summary of changes:
 src/Makefile.am |4 ++--
 src/via_id.c|   16 
 2 files changed, 10 insertions(+), 10 deletions(-)


hooks/post-receive
-- 
X driver for VIA IGPs
___
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel