aboutsummaryrefslogtreecommitdiffstats
path: root/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
blob: 705cffcbf79893a6340bb2ddb3a12e7d596b26fe (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
Upstream-Status: Inappropriate [already upstream]

It's broken for devices with BARs above 4G, and the sysfs method should         
work everywhere anyway.  As a pleasant side effect, this fixes some             
warnings:                                                                       
                                                                                
fbdevhw.c: In function 'fbdev_open_pci':                                        
fbdevhw.c:333:4: warning: cast from pointer to integer of different size        
fbdevhw.c:334:4: warning: cast from pointer to integer of different size        
fbdevhw.c:336:4: warning: cast from pointer to integer of different size        
fbdevhw.c:337:4: warning: cast from pointer to integer of different size        
                                                                                
Signed-off-by: Adam Jackson <ajax (a] redhat.com>                                   
Integrated-by: Tom Zanussi <tom.zanussi (a] intel.com>

Index: xorg-server-1.9.3/hw/xfree86/fbdevhw/fbdevhw.c
===================================================================
--- xorg-server-1.9.3.orig/hw/xfree86/fbdevhw/fbdevhw.c	2012-01-12 10:32:07.097729262 -0600
+++ xorg-server-1.9.3/hw/xfree86/fbdevhw/fbdevhw.c	2012-01-12 10:32:55.076732780 -0600
@@ -291,14 +291,7 @@
 {
     struct	fb_fix_screeninfo fix;
     char	filename[256];
-    int	fd,i,j;
-
-
-    /* There are two ways to that we can determine which fb device is
-     * associated with this PCI device.  The more modern way is to look in
-     * the sysfs directory for the PCI device for a file named
-     * "graphics/fb*"
-     */
+    int	fd, i;
 
     for (i = 0; i < 8; i++) {
 	sprintf(filename, 
@@ -331,55 +324,10 @@
 	}
     }
 
-
-    /* The other way is to examine the resources associated with each fb
-     * device and see if there is a match with the PCI device.  This technique
-     * has some problems on certain mixed 64-bit / 32-bit architectures.
-     * There is a flaw in the fb_fix_screeninfo structure in that it only
-     * returns the low 32-bits of the address of the resources associated with
-     * a device.  However, on a mixed architecture the base addresses of PCI
-     * devices, even for 32-bit applications, may be higher than 0x0f0000000.
-     */
-
-    for (i = 0; i < 8; i++) {
-	sprintf(filename,"/dev/fb%d",i);
-	if (-1 == (fd = open(filename,O_RDWR,0))) {
-	    xf86DrvMsg(-1, X_WARNING,
-		       "open %s: %s\n", filename, strerror(errno));
-	    continue;
-	}
-	if (-1 == ioctl(fd,FBIOGET_FSCREENINFO,(void*)&fix)) {
-	    close(fd);
-	    continue;
-	}
-	for (j = 0; j < 6; j++) {
-	    const pciaddr_t res_start = pPci->regions[j].base_addr;
-	    const pciaddr_t res_end = res_start + pPci->regions[j].size;
-
-	    if ((0 != fix.smem_len &&
-		 (pciaddr_t) fix.smem_start >= res_start &&
-		 (pciaddr_t) fix.smem_start < res_end) ||
-		(0 != fix.mmio_len &&
-		 (pciaddr_t) fix.mmio_start >= res_start &&
-		 (pciaddr_t) fix.mmio_start < res_end))
-	      break;
-	}
-	if (j == 6) {
-	    close(fd);
-	    continue;
-	}
-	if (namep) {
-	    *namep = xnfalloc(16);
-	    strncpy(*namep,fix.id,16);
-	}
-	return fd;
-    }
-
     if (namep)
       *namep = NULL;
 
-    xf86DrvMsg(-1, X_ERROR,
-	       "Unable to find a valid framebuffer device\n");
+    xf86DrvMsg(-1, X_ERROR, "Unable to find a valid framebuffer device\n");
     return -1;
 }